Oskar Linde wrote:
> Coding guidelines would probably say that $ should be assigned to a
> named variable for all but the simplest blocks:
> if (foo()) {
>     auto myvar = $;
>     ...
> }
> The $ would be kind of elusive and only usable in its outermost scope.

That would sort of make the whole token pointless IMO - easier just to do something like:

if ((myvar = foo()) != 0)

or whatever, I'm not sure exactly how the syntax currently works for this.

>     if (auto m = a ~~ b)
> 
> might be a little wordy? Perhaps:
> 
>     if (m; a ~~ b)
> 

I personally like the former, it does not need special 'if' syntax.

Walter Bright wrote:
> "Oskar Linde" <oskar.lindeREM@OVEgmail.com> wrote in message news:dt4nqs$2erg$1@digitaldaemon.com...
> 
>>The apparent innocent change of removing the condition c == d from the if-statement will suddenly and silently have a side effect of injecting a shadowing _match variable and thus alter the argument to do_something().
> 
> 
> Yes, that's a problem.
> 
> 
>>Maybe this is a good time to consider Ben Hinkle's suggested declare-and-init operator := as a non-verbose way of naming sub-expressions.
>>http://www.digitalmars.com/d/archives/digitalmars/D/28198.html
>>(Also similar to Serg Kovrovs suggestion on the Semantic Scope Operator thread)
>>
>>if (m := a ~~ b) {
>>  ...
>>  if (n := c ~~ m.match(0)) {
>>  ...
>>  }
>>}
> 
> 
> It's a workable proposal. But it overlaps the functionality of 'auto' declarations a bit much. And:
> 
>     if (auto m = a ~~ b)
> 
> might be a little wordy? Perhaps:
> 
>     if (m; a ~~ b)
> 
> sort of along the lines of foreach? 
> 

How would this scale to something like

if((a ~~ b) && (c ~~ d))

would it be:

if( m; a~~b && n; c~~d) ?

This looks confusing to me. Wouldn't ':' look better here:

if( m: a~~b && n: c~~d) ?

But I think i like Ben's declare nad init := operator best in this case.

Walter Bright wrote:
> "Sean Kelly" <sean@f4.ca> wrote in message news:dt3hev$1taf$1@digitaldaemon.com...
>> Walter Bright wrote:
>>> I'm just not getting it - why should it be removed? There never was a plan to remove it. And why would an implementation of a D runtime library not want to do a regex implementation? Of course, it's a lot of work to implement a regex, but one can just copy over std.RegExp and use/adapt it as required, as the license allows that. So I am just not getting what the problem is.
>> Perhaps I'm being idealistic, as I simply don't believe the runtime should rely on standard library code.  Up to now that's been achievable, but the solution for this particular feature is less clear.  But I'll drop the issue for now and mull it over a bit.
> 
> Consider that there's no way to implement C, D, etc., without some runtime library. Just doing a long divide relies on library code. There's the startup code (you can't just jmp to main()), shutdown code, exception handling support, etc.

Just to be clear, by "standard library code" I actually meant D code specifically.  I fully expect the standard C library to be used by the D runtime.  But as the C runtime likely calls C standard library functions, I suppose there's little reason to expect otherwise from D.

> C/C++ have gone the odd route of making the library *part of the language*, so, for example, a compiler can recognize strlen and replace it with custom code. To my mind this gives the worst of both worlds - no syntactic sugar and no library flexibility. 

I've heard this mentioned before and it seems a bit odd to me.  Does the spec actually mention this anywhere, or is it merely implied by having the library spec be a part of the language spec?


Sean

Walter Bright wrote:
> "Oskar Linde" <oskar.lindeREM@OVEgmail.com> wrote in message news:dt4nqs$2erg$1@digitaldaemon.com...
> 
>> The apparent innocent change of removing the condition c == d from
>> the if-statement will suddenly and silently have a side effect of
>> injecting a shadowing _match variable and thus alter the argument
>> to do_something().
> 
> 
> Yes, that's a problem.
> 
> 
>> Maybe this is a good time to consider Ben Hinkle's suggested declare-and-init operator := as a non-verbose way of naming sub-expressions. http://www.digitalmars.com/d/archives/digitalmars/D/28198.html (Also similar to Serg Kovrovs suggestion on the Semantic Scope
>> Operator thread)
>> 
>> if (m := a ~~ b) { ... if (n := c ~~ m.match(0)) { ... } }
> 
> 
> It's a workable proposal. But it overlaps the functionality of 'auto'
>  declarations a bit much. And:
> 
> if (auto m = a ~~ b)
> 
> might be a little wordy? Perhaps:
> 
> if (m; a ~~ b)
> 
> sort of along the lines of foreach?

I'm uneasy with this. We're playing with fundamental constructs here.

if( ; )

is something so pivotal, that we should give this careful thought.

If it took us 4 years of hard work to get rid of bit, what will happen when this gets rushed into the language without due diligence?

"Georg Wrede" <georg.wrede@nospam.org> wrote
[snip]
>> if (auto m = a ~~ b)
>>
>> might be a little wordy? Perhaps:
>>
>> if (m; a ~~ b)
>>
>> sort of along the lines of foreach?
>
> I'm uneasy with this. We're playing with fundamental constructs here.
>
> if( ; )
>
> is something so pivotal, that we should give this careful thought.
>
> If it took us 4 years of hard work to get rid of bit, what will happen when this gets rushed into the language without due diligence?

I'm all for getting some kind of regex sugar in the grammar, but also feel a bit alarmed about the sudden rush to 'slam' all this into the language. Seems like it would be wiser to approach this whole thing in smaller steps: let's see how foreach() goes first?

Georg Wrede wrote:
> 
> I'm uneasy with this. We're playing with fundamental constructs here.
> 
> if( ; )
> 
> is something so pivotal, that we should give this careful thought.
> 
> If it took us 4 years of hard work to get rid of bit, what will happen when this gets rushed into the language without due diligence?

True enough.  However, the above syntax is currently illegal, so there's no change of something breaking, and C/C++ already allow declarations in if blocks via the traditional method:

if( int x = foo() ) {}

One of Walter's other suggestions was to use this syntax, with the qualification that it was a bit verbose.

One thing I like about the proposed syntax is that it's already how foreach works, so the semantic meaning is mostly just being extended to if and while blocks.  The 'for' syntax doesn't match this however, which may be one argument in favor of the more traditional 'auto' method.

Personally, my primary interest is that the syntax be both consistent and obvious.  Both of the above work for me, but I favor "if( x; foo() )" if implicit type determination is mandatory.  If it's not, I'm ambivalent.


Sean

Kris wrote:
> 
> I'm all for getting some kind of regex sugar in the grammar, but also feel a bit alarmed about the sudden rush to 'slam' all this into the language. Seems like it would be wiser to approach this whole thing in smaller steps: let's see how foreach() goes first? 

As long as these new features don't break old code, I'm fine with Walter trying things out.  After all, the best way to solicit input is often to give people something to play with.  But it would be nice if there were a way to have these features flagged as "experimental."


Sean

"Sean Kelly" <sean@f4.ca> wrote...
> Kris wrote:
>>
>> I'm all for getting some kind of regex sugar in the grammar, but also feel a bit alarmed about the sudden rush to 'slam' all this into the language. Seems like it would be wiser to approach this whole thing in smaller steps: let's see how foreach() goes first?
>
> As long as these new features don't break old code, I'm fine with Walter trying things out.  After all, the best way to solicit input is often to give people something to play with.  But it would be nice if there were a way to have these features flagged as "experimental."

That would be cool.

On Fri, 17 Feb 2006 15:38:38 +0000, Bruno Medeiros <daiphoenixNO@SPAMlycos.com> wrote:
>> if (flags[5]) //check for flag
>>     flag[5] = 1; //set flag
>>  void foo(long header) {
>>   int length = header[0..5]; //copy bits to lvalue.
>> ....
>>
> An interesting idea, but maybe, to avoid conflicts syntax conflicts, we should have:
>    if (flags.bits[5])
>      flags.bits[5] = 0;
>
> (the name "bits" could maybe be other)

I like it.

Regan