www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - if(;){} opinion

reply Georg Wrede <georg nospam.org> writes:
Better 'fess up front: the intent of this post is to once and for all 
murder, pulverize and extradite the new if construct.

Consider:

         if (m; std.regexp.search("abcdef", "b(c)d"))
         {
             writefln("[%s]", m.pre);      // prints [a]
             writefln("[%s]", m.post);     // prints [ef]
             writefln("[%s]", m.match(0)); // prints [bcd]
             writefln("[%s]", m.match(1)); // prints [c]
             writefln("[%s]", m.match(2)); // prints []
         }

Flauting this around has shown that experienced programmers have a hard 
time figuring out what is going on here.

Consider:

         if (m; std.regexp.search("abcdef", "b(c)d"))

Most everybody take it for granted that here is a typo, the '(m;' must 
be the result of a sloppy copy-paste.

And in the previous case the theories ranged from all kinds of 
behind-the-scenes magic.

Now consider:

         if (Regexp m = std.regexp.search("abcdef", "b(c)d"))
         {
             writefln("[%s]", m.pre);      // prints [a]
             writefln("[%s]", m.post);     // prints [ef]
             writefln("[%s]", m.match(0)); // prints [bcd]
             writefln("[%s]", m.match(1)); // prints [c]
             writefln("[%s]", m.match(2)); // prints []
         }

Flaunting this around (to both the original programmers, and also to 
virgin victims), gave the same, _immediate_ comment from everybody: "Ah, 
that's neat!"
Feb 26 2006
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Georg Wrede" <georg nospam.org> wrote in message 
news:4401ECE3.4030207 nospam.org...
 Better 'fess up front: the intent of this post is to once and for all 
 murder, pulverize and extradite the new if construct.

 Consider:

         if (m; std.regexp.search("abcdef", "b(c)d"))
         {
             writefln("[%s]", m.pre);      // prints [a]
             writefln("[%s]", m.post);     // prints [ef]
             writefln("[%s]", m.match(0)); // prints [bcd]
             writefln("[%s]", m.match(1)); // prints [c]
             writefln("[%s]", m.match(2)); // prints []
         }

 Flauting this around has shown that experienced programmers have a hard 
 time figuring out what is going on here.

 Consider:

         if (m; std.regexp.search("abcdef", "b(c)d"))

 Most everybody take it for granted that here is a typo, the '(m;' must be 
 the result of a sloppy copy-paste.

 And in the previous case the theories ranged from all kinds of 
 behind-the-scenes magic.

 Now consider:

         if (Regexp m = std.regexp.search("abcdef", "b(c)d"))
         {
             writefln("[%s]", m.pre);      // prints [a]
             writefln("[%s]", m.post);     // prints [ef]
             writefln("[%s]", m.match(0)); // prints [bcd]
             writefln("[%s]", m.match(1)); // prints [c]
             writefln("[%s]", m.match(2)); // prints []
         }

 Flaunting this around (to both the original programmers, and also to 
 virgin victims), gave the same, _immediate_ comment from everybody: "Ah, 
 that's neat!"

I can see where the new syntax came from: foreach(Foo x; a) But I'll agree with you that it doesn't seem to make much sense in the context of an if statement. I remember a while ago someone posting a suggestion that the ability to declare and initialize variables in conditional statements be extended from just for (and foreach) to all kinds of statements, such as your suggestion. I do like the "if(type ident = expr)" syntax.
Feb 26 2006
prev sibling next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Georg Wrede" <georg nospam.org> wrote in message 
news:4401ECE3.4030207 nospam.org...
 Now consider:

         if (Regexp m = std.regexp.search("abcdef", "b(c)d"))
         {
             writefln("[%s]", m.pre);      // prints [a]
             writefln("[%s]", m.post);     // prints [ef]
             writefln("[%s]", m.match(0)); // prints [bcd]
             writefln("[%s]", m.match(1)); // prints [c]
             writefln("[%s]", m.match(2)); // prints []
         }

 Flaunting this around (to both the original programmers, and also to 
 virgin victims), gave the same, _immediate_ comment from everybody: "Ah, 
 that's neat!"

The idea behind m; was to be like foreach. What do the "victims" <g> think of: if (auto m = std.regexp.search("abcdef", "b(c)d")) ?
Feb 26 2006
next sibling parent Georg Wrede <georg nospam.org> writes:
Walter Bright wrote:
 "Georg Wrede" <georg nospam.org> wrote in message 
 news:4401ECE3.4030207 nospam.org...
 
Now consider:

        if (Regexp m = std.regexp.search("abcdef", "b(c)d"))
        {
            writefln("[%s]", m.pre);      // prints [a]
            writefln("[%s]", m.post);     // prints [ef]
            writefln("[%s]", m.match(0)); // prints [bcd]
            writefln("[%s]", m.match(1)); // prints [c]
            writefln("[%s]", m.match(2)); // prints []
        }

Flaunting this around (to both the original programmers, and also to 
virgin victims), gave the same, _immediate_ comment from everybody: "Ah, 
that's neat!"

The idea behind m; was to be like foreach. What do the "victims" <g> think of: if (auto m = std.regexp.search("abcdef", "b(c)d"))

Can't give a statistical answer at this hour, but with one of them I actually brought it up. He thought it would be no problem, even to somebody not familiar with the language from before.
Feb 26 2006
prev sibling next sibling parent "Chris Miller" <chris dprogramming.com> writes:
On Sun, 26 Feb 2006 13:43:55 -0500, Walter Bright  
<newshound digitalmars.com> wrote:

 "Georg Wrede" <georg nospam.org> wrote in message
 news:4401ECE3.4030207 nospam.org...
 Now consider:

         if (Regexp m = std.regexp.search("abcdef", "b(c)d"))
         {
             writefln("[%s]", m.pre);      // prints [a]
             writefln("[%s]", m.post);     // prints [ef]
             writefln("[%s]", m.match(0)); // prints [bcd]
             writefln("[%s]", m.match(1)); // prints [c]
             writefln("[%s]", m.match(2)); // prints []
         }

 Flaunting this around (to both the original programmers, and also to
 virgin victims), gave the same, _immediate_ comment from everybody: "Ah,
 that's neat!"

The idea behind m; was to be like foreach. What do the "victims" <g> think of: if (auto m = std.regexp.search("abcdef", "b(c)d")) ?

That's what I was thinking, and perhaps it can be generalized to allow a declaration in any expression; allowing: while(auto foo = bar) { } baz(auto Foo f = new Foo); // RAII, f being destructed when baz() returns. etc
Feb 26 2006
prev sibling next sibling parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Walter Bright wrote:
 "Georg Wrede" <georg nospam.org> wrote in message 
 news:4401ECE3.4030207 nospam.org...
 Now consider:

         if (Regexp m = std.regexp.search("abcdef", "b(c)d"))
         {
             writefln("[%s]", m.pre);      // prints [a]
             writefln("[%s]", m.post);     // prints [ef]
             writefln("[%s]", m.match(0)); // prints [bcd]
             writefln("[%s]", m.match(1)); // prints [c]
             writefln("[%s]", m.match(2)); // prints []
         }

 Flaunting this around (to both the original programmers, and also to 
 virgin victims), gave the same, _immediate_ comment from everybody: "Ah, 
 that's neat!"

The idea behind m; was to be like foreach. What do the "victims" <g> think of: if (auto m = std.regexp.search("abcdef", "b(c)d"))

That makes a lot more sense. Although I prefer if(type variable, variable = expression, expression == something) {...} or if(auto variable = expression, expression == something) {...} Unfortunately it's currently not possible (at least don't know how to do it) to declare anything that 'permanent' with the expression-comma-expression -syntax. I guess the scope ends, when the next comma is encountered. It would be very nice to support the comma-notation like above inside if-, while- and for-statements and stop supporting the current implementation elsewhere. IMO it's pretty useless outside these three statements. There's also other use for commas (e.g. initializing multi-dimensional arrays). I've proposed this before since the syntax for dynamic arrays is a bit weak at the moment. -- Jari-Matti
Feb 26 2006
prev sibling next sibling parent "Lionello Lunesu" <lio remove.lunesu.com> writes:
 The idea behind m; was to be like foreach. What do the "victims" <g> think 
 of:

 if (auto m = std.regexp.search("abcdef", "b(c)d"))

That's what I'm used to! And no need for any "new stuff" either. I prefer this way. L.
Feb 27 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
 "Georg Wrede" <georg nospam.org> wrote in message 
 news:4401ECE3.4030207 nospam.org...
 
Now consider:

        if (Regexp m = std.regexp.search("abcdef", "b(c)d"))
        {
            writefln("[%s]", m.pre);      // prints [a]
            writefln("[%s]", m.post);     // prints [ef]
            writefln("[%s]", m.match(0)); // prints [bcd]
            writefln("[%s]", m.match(1)); // prints [c]
            writefln("[%s]", m.match(2)); // prints []
        }

 Flaunting this around (to both the original programmers, and also
 to virgin victims), gave the same, _immediate_ comment from
 everybody: "Ah, that's neat!"

The idea behind m; was to be like foreach. What do the "victims" <g> think of: if (auto m = std.regexp.search("abcdef", "b(c)d"))

Another round, and everyone had no problem immediately understanding the code. And the word "auto" was universally assumed as in "autotype". Found one "still virgin" non-D programmer, and even he immediately assumed the correct functionality, and took for granted that "auto" meant that the compiler figures out the actual type.
Feb 28 2006
next sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:44047C36.8060200 nospam.org...
 Walter Bright wrote:
 The idea behind m; was to be like foreach. What do the "victims" <g>
 think of:

 if (auto m = std.regexp.search("abcdef", "b(c)d"))

Another round, and everyone had no problem immediately understanding the code. And the word "auto" was universally assumed as in "autotype". Found one "still virgin" non-D programmer, and even he immediately assumed the correct functionality, and took for granted that "auto" meant that the compiler figures out the actual type.

Thanks for doing this. The result is pretty clear <g>.
Feb 28 2006
prev sibling parent "Derek Parnell" <derek psych.ward> writes:
On Wed, 01 Mar 2006 03:37:10 +1100, Georg Wrede <georg.wrede nospam.org>  
wrote:

 Flaunting this around (to both the original programmers, and also
 to virgin victims), gave the same, _immediate_ comment from
 everybody: "Ah, that's neat!"

think of: if (auto m = std.regexp.search("abcdef", "b(c)d"))

Another round, and everyone had no problem immediately understanding the code. And the word "auto" was universally assumed as in "autotype". Found one "still virgin" non-D programmer, and even he immediately assumed the correct functionality, and took for granted that "auto" meant that the compiler figures out the actual type.

Georg, you have done a great service to the D language with this market research. I hope the boss addresses it appropriately. -- Derek Parnell Melbourne, Australia
Feb 28 2006
prev sibling next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Honestly, I must agree that I prefer:

if (auto m = foo())

Or even:

if (auto m; foo())

To:

if (m; foo())

Or *most certainly*:

if (m = foo())

We have types everywhere else in the language (although in places we can 
leave them off) so it doesn't seem strange here either.  I can imagine 
wanting, even, to ASSERT that I'm getting an int from the function.  If 
this changes to a class, my code probably won't work anymore anyway.

-[Unknown]


 Better 'fess up front: the intent of this post is to once and for all 
 murder, pulverize and extradite the new if construct.
 
 Consider:
 
         if (m; std.regexp.search("abcdef", "b(c)d"))
         {
             writefln("[%s]", m.pre);      // prints [a]
             writefln("[%s]", m.post);     // prints [ef]
             writefln("[%s]", m.match(0)); // prints [bcd]
             writefln("[%s]", m.match(1)); // prints [c]
             writefln("[%s]", m.match(2)); // prints []
         }
 
 Flauting this around has shown that experienced programmers have a hard 
 time figuring out what is going on here.
 
 Consider:
 
         if (m; std.regexp.search("abcdef", "b(c)d"))
 
 Most everybody take it for granted that here is a typo, the '(m;' must 
 be the result of a sloppy copy-paste.
 
 And in the previous case the theories ranged from all kinds of 
 behind-the-scenes magic.
 
 Now consider:
 
         if (Regexp m = std.regexp.search("abcdef", "b(c)d"))
         {
             writefln("[%s]", m.pre);      // prints [a]
             writefln("[%s]", m.post);     // prints [ef]
             writefln("[%s]", m.match(0)); // prints [bcd]
             writefln("[%s]", m.match(1)); // prints [c]
             writefln("[%s]", m.match(2)); // prints []
         }
 
 Flaunting this around (to both the original programmers, and also to 
 virgin victims), gave the same, _immediate_ comment from everybody: "Ah, 
 that's neat!"

Feb 26 2006
parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
 if (m = foo())

This one is tricky, since the programmer might have meant "==", but an explicit declaration might take care of that, I mean, one would be forced to add the type or "auto". Talking of which: when is that "auto" ambiguity going to be resolved? (I still prefer "var" to "auto", but then again the RAII "auto" could use a rename too) L.
Feb 27 2006
parent reply Nils Hensel <nils.hensel web.de> writes:
Lionello Lunesu schrieb:
 Talking of which: when is that "auto" ambiguity going to be resolved? (I 
 still prefer "var" to "auto"

This would get my vote as well. "var" is far more intuitive and it would be similar to DScript. I don't think there's an obvious connection between "auto" and the data type of a variable. Nils
Feb 27 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
On Mon, 27 Feb 2006 22:25:37 +1100, Nils Hensel <nils.hensel web.de> wrote:

 Lionello Lunesu schrieb:
 Talking of which: when is that "auto" ambiguity going to be resolved?  
 (I still prefer "var" to "auto"

This would get my vote as well. "var" is far more intuitive and it would be similar to DScript. I don't think there's an obvious connection between "auto" and the data type of a variable.

Thanks! There has been something bugging me about this since it appeared and that is it. True its an 'auto' but an auto what? Auto scope? Auto Type? Auto mobile? Auto initialization? Simply, 'auto' is way too ambiguous. At least 'var' is more focused. -- Derek Parnell Melbourne, Australia
Feb 27 2006
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Derek Parnell wrote:
 On Mon, 27 Feb 2006 22:25:37 +1100, Nils Hensel <nils.hensel web.de> wrote:
 
 Lionello Lunesu schrieb:

 Talking of which: when is that "auto" ambiguity going to be 
 resolved?  (I still prefer "var" to "auto"

This would get my vote as well. "var" is far more intuitive and it would be similar to DScript. I don't think there's an obvious connection between "auto" and the data type of a variable.

Thanks! There has been something bugging me about this since it appeared and that is it. True its an 'auto' but an auto what? Auto scope? Auto Type? Auto mobile? Auto initialization? Simply, 'auto' is way too ambiguous. At least 'var' is more focused.

I agree.
Feb 27 2006
prev sibling next sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
Derek Parnell escribió:
 On Mon, 27 Feb 2006 22:25:37 +1100, Nils Hensel <nils.hensel web.de> wrote:
 
 Lionello Lunesu schrieb:
 Talking of which: when is that "auto" ambiguity going to be resolved? 
 (I still prefer "var" to "auto"

This would get my vote as well. "var" is far more intuitive and it would be similar to DScript. I don't think there's an obvious connection between "auto" and the data type of a variable.

Thanks! There has been something bugging me about this since it appeared and that is it. True its an 'auto' but an auto what? Auto scope? Auto Type? Auto mobile? Auto initialization? Simply, 'auto' is way too ambiguous. At least 'var' is more focused. --Derek Parnell Melbourne, Australia

I prefer auto for auto typing rather than for auto destruction. Preferences... -- Carlos Santander Bernal
Feb 27 2006
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 27 Feb 2006 17:14:28 -0500, Carlos Santander wrote:

 Derek Parnell escribió:
 On Mon, 27 Feb 2006 22:25:37 +1100, Nils Hensel <nils.hensel web.de> wrote:
 
 Lionello Lunesu schrieb:
 Talking of which: when is that "auto" ambiguity going to be resolved? 
 (I still prefer "var" to "auto"

This would get my vote as well. "var" is far more intuitive and it would be similar to DScript. I don't think there's an obvious connection between "auto" and the data type of a variable.

Thanks! There has been something bugging me about this since it appeared and that is it. True its an 'auto' but an auto what? Auto scope? Auto Type? Auto mobile? Auto initialization? Simply, 'auto' is way too ambiguous. At least 'var' is more focused. --Derek Parnell Melbourne, Australia

I prefer auto for auto typing rather than for auto destruction. Preferences...

But that's my point ... 'auto' by itself is ambiguous and for a first-timer to understand it depends somewhat on one's preconceptions and preferences. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 28/02/2006 9:37:39 AM
Feb 27 2006
next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Derek Parnell wrote:
 On Mon, 27 Feb 2006 17:14:28 -0500, Carlos Santander wrote:
 
 
 Derek Parnell escribió:
 
 On Mon, 27 Feb 2006 22:25:37 +1100, Nils Hensel
 <nils.hensel web.de> wrote:
 
 
 Lionello Lunesu schrieb:
 
 Talking of which: when is that "auto" ambiguity going to be
 resolved? (I still prefer "var" to "auto"

This would get my vote as well. "var" is far more intuitive and it would be similar to DScript. I don't think there's an obvious connection between "auto" and the data type of a variable.

Thanks! There has been something bugging me about this since it appeared and that is it. True its an 'auto' but an auto what? Auto scope? Auto Type? Auto mobile? Auto initialization? Simply, 'auto' is way too ambiguous. At least 'var' is more focused. --Derek Parnell Melbourne, Australia

I prefer auto for auto typing rather than for auto destruction. Preferences...

But that's my point ... 'auto' by itself is ambiguous and for a first-timer to understand it depends somewhat on one's preconceptions and preferences.

I agree. auto for types is barely bearable. But something better should be invented. Personally I'd even settle for "var", in the worst case. auto for RAII is not even barely bearable. We could even use "raii" rather than "auto". At least it wouldn't be ambiguous or opaque.
Feb 27 2006
next sibling parent reply "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:4403B499.2060300 nospam.org...
 Derek Parnell wrote:
 On Mon, 27 Feb 2006 17:14:28 -0500, Carlos Santander wrote:


 Derek Parnell escribió:

 On Mon, 27 Feb 2006 22:25:37 +1100, Nils Hensel
 <nils.hensel web.de> wrote:


 Lionello Lunesu schrieb:

 Talking of which: when is that "auto" ambiguity going to be
 resolved? (I still prefer "var" to "auto"

This would get my vote as well. "var" is far more intuitive and it would be similar to DScript. I don't think there's an obvious connection between "auto" and the data type of a variable.

Thanks! There has been something bugging me about this since it appeared and that is it. True its an 'auto' but an auto what? Auto scope? Auto Type? Auto mobile? Auto initialization? Simply, 'auto' is way too ambiguous. At least 'var' is more focused. --Derek Parnell Melbourne, Australia

I prefer auto for auto typing rather than for auto destruction. Preferences...

But that's my point ... 'auto' by itself is ambiguous and for a first-timer to understand it depends somewhat on one's preconceptions and preferences.

I agree. auto for types is barely bearable. But something better should be invented. Personally I'd even settle for "var", in the worst case. auto for RAII is not even barely bearable. We could even use "raii" rather than "auto". At least it wouldn't be ambiguous or opaque.

Feb 27 2006
parent "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"Ameer Armaly" <ameer_armaly hotmail.com> wrote in message 
news:du0dh5$5v6$1 digitaldaemon.com...
 "Georg Wrede" <georg.wrede nospam.org> wrote in message 
 news:4403B499.2060300 nospam.org...
 Derek Parnell wrote:
 On Mon, 27 Feb 2006 17:14:28 -0500, Carlos Santander wrote:


 Derek Parnell escribió:

 On Mon, 27 Feb 2006 22:25:37 +1100, Nils Hensel
 <nils.hensel web.de> wrote:


 Lionello Lunesu schrieb:

 Talking of which: when is that "auto" ambiguity going to be
 resolved? (I still prefer "var" to "auto"

This would get my vote as well. "var" is far more intuitive and it would be similar to DScript. I don't think there's an obvious connection between "auto" and the data type of a variable.

Thanks! There has been something bugging me about this since it appeared and that is it. True its an 'auto' but an auto what? Auto scope? Auto Type? Auto mobile? Auto initialization? Simply, 'auto' is way too ambiguous. At least 'var' is more focused. --Derek Parnell Melbourne, Australia

I prefer auto for auto typing rather than for auto destruction. Preferences...

But that's my point ... 'auto' by itself is ambiguous and for a first-timer to understand it depends somewhat on one's preconceptions and preferences.

I agree. auto for types is barely bearable. But something better should be invented. Personally I'd even settle for "var", in the worst case.


 auto for RAII is not even barely bearable. We could even use "raii" 
 rather than "auto". At least it wouldn't be ambiguous or opaque.


Feb 27 2006
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:4403B499.2060300 nospam.org...
 auto for RAII is not even barely bearable. We could even use "raii" rather 
 than "auto".

Why not "rr"? Oh Georg, your personal acronyms ;)
Feb 27 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:du0hqu$a7i$1 digitaldaemon.com...
 "Georg Wrede" <georg.wrede nospam.org> wrote in message 
 news:4403B499.2060300 nospam.org...
 auto for RAII is not even barely bearable. We could even use "raii" 
 rather than "auto".


On a more serious note, I think auto for RAII makes some sense. After all, the original meaning of auto in C is that the variable gets "cleaned up" and "goes away" when the scope exits. The same applies for RAII, although perhaps since there has been an acronym invented to describe this behavior, it should be used instead. Though I will have to say that "auto" looks prettier than "raii."
Feb 27 2006
prev sibling parent Carlos Santander <csantander619 gmail.com> writes:
Derek Parnell escribió:
 On Mon, 27 Feb 2006 17:14:28 -0500, Carlos Santander wrote:
 
 I prefer auto for auto typing rather than for auto destruction. Preferences...

But that's my point ... 'auto' by itself is ambiguous and for a first-timer to understand it depends somewhat on one's preconceptions and preferences.

You're right, but that's unavoidable. Someone waking up from 15 years ago, having only programmed in assembler, would have a hard time understanding "int" is not for "interrupt". I know that's extreme, but it's just to make my point. I think we all agree "auto" shouldn't be used for both cases. Walter just should pick one and use another syntax for the other. All we can do regarding that is give our input. In my case, I don't think I've ever had a variable/function/class/module named "auto", but I've had many variables "var". I think I've only stated the obvious, but I just felt like I had to say it. -- Carlos Santander Bernal
Feb 27 2006
prev sibling parent reply Charles <noone nowhere.com> writes:
I think its short for 'auto' deduction ?

'var' gets my vote

Derek Parnell wrote:
 On Mon, 27 Feb 2006 22:25:37 +1100, Nils Hensel <nils.hensel web.de> wrote:
 
 Lionello Lunesu schrieb:

 Talking of which: when is that "auto" ambiguity going to be 
 resolved?  (I still prefer "var" to "auto"

This would get my vote as well. "var" is far more intuitive and it would be similar to DScript. I don't think there's an obvious connection between "auto" and the data type of a variable.

Thanks! There has been something bugging me about this since it appeared and that is it. True its an 'auto' but an auto what? Auto scope? Auto Type? Auto mobile? Auto initialization? Simply, 'auto' is way too ambiguous. At least 'var' is more focused.

Feb 27 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Charles" <noone nowhere.com> wrote in message 
news:du002j$2pcm$1 digitaldaemon.com...
I think its short for 'auto' deduction ?

 'var' gets my vote

'auto' goes way back to C and means "allocate on the stack". This also implicitly means "destruct at end of scope." In order for type inference to work, there has to be a keyword in front of the declaration to let the parser know it's a declaration rather than an assignment. Thus, 'auto' now means "allocate on the stack" and if the type is missing it also means "infer the type." Types can be inferred with other storage classes: static x = 3; // x is int This follows the 'auto' proposal for C++ as far as I know. 'var' would be a digression into pascalishness (ugh <g>).
Feb 27 2006
next sibling parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:du0sll$lj0$1 digitaldaemon.com...
 "Charles" <noone nowhere.com> wrote in message 
 news:du002j$2pcm$1 digitaldaemon.com...
I think its short for 'auto' deduction ?

 'var' gets my vote

'auto' goes way back to C and means "allocate on the stack". This also implicitly means "destruct at end of scope." In order for type inference to work, there has to be a keyword in front of the declaration to let the parser know it's a declaration rather than an assignment. Thus, 'auto' now means "allocate on the stack" and if the type is missing it also means "infer the type." Types can be inferred with other storage classes: static x = 3; // x is int This follows the 'auto' proposal for C++ as far as I know.

Do you mean the two seemingly different "auto"s are not ambigious?
 'var' would be a digression into pascalishness (ugh <g>).

I'm just glad you didn't use this argument against array slicing ; ) L.
Feb 28 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Lionello Lunesu" <lio remove.lunesu.com> wrote in message 
news:du10fg$q5p$1 digitaldaemon.com...
 Do you mean the two seemingly different "auto"s are not ambigious?

That's right.
 'var' would be a digression into pascalishness (ugh <g>).


Pascal doesn't do array slicing.
Feb 28 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Tue, 28 Feb 2006 21:03:14 +1100, Walter Bright  
<newshound digitalmars.com> wrote:

 "Lionello Lunesu" <lio remove.lunesu.com> wrote in message
 news:du10fg$q5p$1 digitaldaemon.com...
 Do you mean the two seemingly different "auto"s are not ambigious?

That's right.

I've forgotten: what's the syntax to automatically allocate on the static, a variable whose type is automatically type-cast? Is it ... auto auto x = readtext(somefile); -- Derek Parnell Melbourne, Australia
Feb 28 2006
next sibling parent "Lionello Lunesu" <lio remove.lunesu.com> writes:
Walter said:
 Thus, 'auto' now means "allocate on the stack" and if the type is 
 missing it also means "infer the type."




So I suppose 1 "auto" would suffice. L. "Derek Parnell" <derek psych.ward> wrote in message news:op.s5ol8l1e6b8z09 ginger.vic.bigpond.net.au...
 On Tue, 28 Feb 2006 21:03:14 +1100, Walter Bright 
 <newshound digitalmars.com> wrote:

 "Lionello Lunesu" <lio remove.lunesu.com> wrote in message
 news:du10fg$q5p$1 digitaldaemon.com...
 Do you mean the two seemingly different "auto"s are not ambigious?

That's right.

I've forgotten: what's the syntax to automatically allocate on the static, a variable whose type is automatically type-cast? Is it ... auto auto x = readtext(somefile); -- Derek Parnell Melbourne, Australia

Feb 28 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:op.s5ol8l1e6b8z09 ginger.vic.bigpond.net.au...
 I've forgotten: what's the syntax to automatically allocate on the static, 
 a variable whose type is automatically type-cast? Is it ...

    auto auto x = readtext(somefile);

automatically allocate on the static? I don't understand.
Feb 28 2006
parent "Derek Parnell" <derek psych.ward> writes:
On Wed, 01 Mar 2006 06:20:35 +1100, Walter Bright  
<newshound digitalmars.com> wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:op.s5ol8l1e6b8z09 ginger.vic.bigpond.net.au...
 I've forgotten: what's the syntax to automatically allocate on the  
 static,
 a variable whose type is automatically type-cast? Is it ...

    auto auto x = readtext(somefile);

automatically allocate on the static? I don't understand.

LOL... "static" is a mispelled "stack" sorry for my late night typing. -- Derek Parnell Melbourne, Australia
Feb 28 2006
prev sibling parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:du187d$14bk$2 digitaldaemon.com...
 "Lionello Lunesu" <lio remove.lunesu.com> wrote in message 
 news:du10fg$q5p$1 digitaldaemon.com...
 Do you mean the two seemingly different "auto"s are not ambigious?

That's right.
 'var' would be a digression into pascalishness (ugh <g>).


Pascal doesn't do array slicing.

Probably GPC specific then: http://www.gnu-pascal.de/gpc/String-Slice-Access.html Although the notation array[x..y] was already used in 'normal' Pascal when declaring arrays. L.
Feb 28 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Lionello Lunesu" <lio remove.lunesu.com> wrote in message 
news:du1lnl$1ko0$1 digitaldaemon.com...
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:du187d$14bk$2 digitaldaemon.com...
 Pascal doesn't do array slicing.

Probably GPC specific then: http://www.gnu-pascal.de/gpc/String-Slice-Access.html

The article does say it is for "Extended" Pascal. That's the trouble with Pascal - it is unusable as defined. Every useful implementation found it necessary to add numerous extensions.
 Although the notation array[x..y] was already used in 'normal' Pascal when 
 declaring arrays.

Yes, but that isn't array slicing, it's more of a way to set the index for the 'zeroth' element. This is not supported in D. Pascalish nested functions, however, *are* in D <g>. That was the only Pascal characteristic I missed.
Feb 28 2006
prev sibling next sibling parent Nils Hensel <nils.hensel web.de> writes:
Walter Bright schrieb:
 'var' would be a digression into pascalishness (ugh <g>). 

JavaScript and C# which use it in the same fashion as D does with "auto".Changing to "var" would be more intuitive to a large group of people. People with a long History of C/C++ are likely to be new to the concept of dynamic typing anyway so they might as well learn a new keyword. But I agree with you that Pascal's way of "var" meaning "call by reference" is equally unintuitve. Just my 0.02 EuroCent Nils
Feb 28 2006
prev sibling next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Tue, 28 Feb 2006 17:44:28 +1100, Walter Bright  
<newshound digitalmars.com> wrote:

 "Charles" <noone nowhere.com> wrote in message
 news:du002j$2pcm$1 digitaldaemon.com...
 I think its short for 'auto' deduction ?

 'var' gets my vote

'auto' goes way back to C and means "allocate on the stack". This also implicitly means "destruct at end of scope." In order for type inference to work, there has to be a keyword in front of the declaration to let the parser know it's a declaration rather than an assignment. Thus, 'auto' now means "allocate on the stack" and if the type is missing it also means "infer the type." Types can be inferred with other storage classes: static x = 3; // x is int This follows the 'auto' proposal for C++ as far as I know. 'var' would be a digression into pascalishness (ugh <g>).

Language Bigot! <G> Seriously though ... who cares if its a C thingy! This is NOT C. But you already know that. Just because C does 'X' is it good enough to justify keeping 'X'? You've already changed lots of other things to achieve a better, consistent, language - so why stop at this wart. 'auto', as a word, is too ambiguous to because it is an adjective that can apply to many things. Ok, so C applys it to automatic stack allocation and so does D, but D also applies it to automatic type-casting too. Why do you want your language to be ridiculed for this wart when it is so easy to change it. If you are too frightened of it being a Pascal-looking language (and 'var' will not do that, BTW), then pick some other more meaningful word. -- Derek Parnell Melbourne, Australia
Feb 28 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:op.s5olyeuu6b8z09 ginger.vic.bigpond.net.au...
 Language Bigot! <G>

I plead guilty as charged.
 Seriously though ... who cares if its a C thingy! This is NOT C.

It is a C derived language, and is meant to be an upgrade path for C users. Hence, gratuitous incompatibility is not a good idea. To diverge a particular feature from C, one needs a better reason than just liking a different spelling.
 But you  already know that. Just because C does 'X' is it good enough to 
 justify  keeping 'X'? You've already changed lots of other things to 
 achieve a  better, consistent, language - so why stop at this wart.

 'auto', as a word, is too ambiguous to because it is an adjective that can 
 apply to many things. Ok, so C applys it to automatic stack allocation and 
 so does D, but D also applies it to automatic type-casting too. Why do you 
 want your language to be ridiculed for this wart when it is so easy to 
 change it. If you are too frightened of it being a Pascal-looking language 
 (and 'var' will not do that, BTW), then pick some other more meaningful 
 word.

It isn't ambigous since it doesn't really imply type inference - all it does is enable the parser to disambiguate an expression from a declaration: a = 3; // declaration of 'a' with implicit typing? Or assign to 'a'? auto a = 3; // ahh, now I know it's a declaration static a = 3; // that's a declaration with implicit typing as well
Feb 28 2006
prev sibling next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Walter Bright wrote:
 'var' would be a digression into pascalishness (ugh <g>). 

Just pretend it's from ECMAScript :P -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y ------END GEEK CODE BLOCK------ Tomasz Stachowiak /+ a.k.a. h3r3tic +/
Feb 28 2006
prev sibling next sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Walter Bright wrote:
 "Charles" <noone nowhere.com> wrote in message 
 news:du002j$2pcm$1 digitaldaemon.com...
 I think its short for 'auto' deduction ?

 'var' gets my vote

'auto' goes way back to C and means "allocate on the stack". This also implicitly means "destruct at end of scope." In order for type inference to work, there has to be a keyword in front of the declaration to let the parser know it's a declaration rather than an assignment. Thus, 'auto' now means "allocate on the stack" and if the type is missing it also means "infer the type." Types can be inferred with other storage classes: static x = 3; // x is int This follows the 'auto' proposal for C++ as far as I know.

This is damn AWFUL. No autotype declaration should work without the the autotype keyword! And I don't care if if deviates from the C++ or not, it's just plain bad. *angry face*
 'var' would be a digression into pascalishness (ugh <g>). 
 

what would be the problem?? What matters in a feature/design is how good it is, not if it is similar to other languages or not. -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Feb 28 2006
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Bruno Medeiros wrote:
 Walter Bright wrote:
 "Charles" <noone nowhere.com> wrote in message
 news:du002j$2pcm$1 digitaldaemon.com...
 I think its short for 'auto' deduction ?

 'var' gets my vote

'auto' goes way back to C and means "allocate on the stack". This also implicitly means "destruct at end of scope." In order for type inference to work, there has to be a keyword in front of the declaration to let the parser know it's a declaration rather than an assignment. Thus, 'auto' now means "allocate on the stack" and if the type is missing it also means "infer the type." Types can be inferred with other storage classes: static x = 3; // x is int This follows the 'auto' proposal for C++ as far as I know.

This is damn AWFUL. No autotype declaration should work without the the autotype keyword! And I don't care if if deviates from the C++ or not, it's just plain bad. *angry face*
 'var' would be a digression into pascalishness (ugh <g>).

what would be the problem?? What matters in a feature/design is how good it is, not if it is similar to other languages or not.

That's true. And many other "good" features like with-statements in D originate from Pascal. IMO the worst things in Pascal are variable declarations and too long keywords, otherwise it's damn illustrative and rational language. -- Jari-Matti
Feb 28 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Jari-Matti Mäkelä" <jmjmak utu.fi.invalid> wrote in message 
news:du25uo$29f3$1 digitaldaemon.com...
 IMO the worst things in Pascal are variable
 declarations and too long keywords, otherwise it's damn illustrative and
 rational language.

Yet Pascal was buried by the arrival of C, despite having a long head start on the PC.
Feb 28 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 "Charles" <noone nowhere.com> wrote in message 
 news:du002j$2pcm$1 digitaldaemon.com...
 I think its short for 'auto' deduction ?

 'var' gets my vote

'auto' goes way back to C and means "allocate on the stack". This also implicitly means "destruct at end of scope." In order for type inference to work, there has to be a keyword in front of the declaration to let the parser know it's a declaration rather than an assignment. Thus, 'auto' now means "allocate on the stack" and if the type is missing it also means "infer the type."

Hold on. Certainly you aren't suggesting that "auto myClass = new MyClass()" constructs an object that will be destroyed on scope exit? And if so, how do I auto-type objects without the RAII functionality? Sean
Feb 28 2006
prev sibling next sibling parent reply David Medlock <noone nowhere.com> writes:
Georg Wrede wrote:
 Better 'fess up front: the intent of this post is to once and for all 
 murder, pulverize and extradite the new if construct.
 
 Consider:
 
         if (m; std.regexp.search("abcdef", "b(c)d"))
         {
             writefln("[%s]", m.pre);      // prints [a]
             writefln("[%s]", m.post);     // prints [ef]
             writefln("[%s]", m.match(0)); // prints [bcd]
             writefln("[%s]", m.match(1)); // prints [c]
             writefln("[%s]", m.match(2)); // prints []
         }
 
 Flauting this around has shown that experienced programmers have a hard 
 time figuring out what is going on here.
 
 Consider:
 
         if (m; std.regexp.search("abcdef", "b(c)d"))
 
 Most everybody take it for granted that here is a typo, the '(m;' must 
 be the result of a sloppy copy-paste.
 
 And in the previous case the theories ranged from all kinds of 
 behind-the-scenes magic.
 
 Now consider:
 
         if (Regexp m = std.regexp.search("abcdef", "b(c)d"))
         {
             writefln("[%s]", m.pre);      // prints [a]
             writefln("[%s]", m.post);     // prints [ef]
             writefln("[%s]", m.match(0)); // prints [bcd]
             writefln("[%s]", m.match(1)); // prints [c]
             writefln("[%s]", m.match(2)); // prints []
         }
 
 Flaunting this around (to both the original programmers, and also to 
 virgin victims), gave the same, _immediate_ comment from everybody: "Ah, 
 that's neat!"

I would say extend the with(...) construct to silently fail( and take an else clause ) if the object of the with statement is null. with( Regexp m = std.regexp.search(...) ) { ... } else { ... } Of course foreach is still preferred for multi returned values. -DavidM
Feb 27 2006
next sibling parent "Lionello Lunesu" <lio remove.lunesu.com> writes:
 with( Regexp m = std.regexp.search(...) )
 {
   ...
 }
 else { ... }

I like that "else"! Sure makes that code nicer than the following (equivalent) code: # Regexp m = std.regexp.search(...); # if (m) { # with(m) { # ... # } # } # else { ... } L.
Feb 27 2006
prev sibling next sibling parent Charles <noone nowhere.com> writes:
Nice, this gets my vote.

David Medlock wrote:
 Georg Wrede wrote:
 
 Better 'fess up front: the intent of this post is to once and for all 
 murder, pulverize and extradite the new if construct.

 Consider:

         if (m; std.regexp.search("abcdef", "b(c)d"))
         {
             writefln("[%s]", m.pre);      // prints [a]
             writefln("[%s]", m.post);     // prints [ef]
             writefln("[%s]", m.match(0)); // prints [bcd]
             writefln("[%s]", m.match(1)); // prints [c]
             writefln("[%s]", m.match(2)); // prints []
         }

 Flauting this around has shown that experienced programmers have a 
 hard time figuring out what is going on here.

 Consider:

         if (m; std.regexp.search("abcdef", "b(c)d"))

 Most everybody take it for granted that here is a typo, the '(m;' must 
 be the result of a sloppy copy-paste.

 And in the previous case the theories ranged from all kinds of 
 behind-the-scenes magic.

 Now consider:

         if (Regexp m = std.regexp.search("abcdef", "b(c)d"))
         {
             writefln("[%s]", m.pre);      // prints [a]
             writefln("[%s]", m.post);     // prints [ef]
             writefln("[%s]", m.match(0)); // prints [bcd]
             writefln("[%s]", m.match(1)); // prints [c]
             writefln("[%s]", m.match(2)); // prints []
         }

 Flaunting this around (to both the original programmers, and also to 
 virgin victims), gave the same, _immediate_ comment from everybody: 
 "Ah, that's neat!"

I would say extend the with(...) construct to silently fail( and take an else clause ) if the object of the with statement is null. with( Regexp m = std.regexp.search(...) ) { ... } else { ... } Of course foreach is still preferred for multi returned values. -DavidM

Feb 27 2006
prev sibling next sibling parent BCS <BCS_member pathlink.com> writes:
I like it

How about for the Synchronize statement. To be fair I think something like that 
has also bean suggested with Foreach.


David Medlock wrote:
 
 
 I would say extend the with(...) construct to silently fail( and take an 
 else clause ) if the object of the with statement is null.
 
 with( Regexp m = std.regexp.search(...) )
 {
   ...
 }
 else { ... }
 
 Of course foreach is still preferred for multi returned values.
 
 -DavidM
 

Feb 27 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
David Medlock wrote:
 Georg Wrede wrote:
 
 Better 'fess up front: the intent of this post is to once and for all 
 murder, pulverize and extradite the new if construct.

 Consider:

         if (m; std.regexp.search("abcdef", "b(c)d"))
         {
             writefln("[%s]", m.pre);      // prints [a]
             writefln("[%s]", m.post);     // prints [ef]
             writefln("[%s]", m.match(0)); // prints [bcd]
             writefln("[%s]", m.match(1)); // prints [c]
             writefln("[%s]", m.match(2)); // prints []
         }

 Flauting this around has shown that experienced programmers have a 
 hard time figuring out what is going on here.


 
 I would say extend the with(...) construct to silently fail( and take an 
 else clause ) if the object of the with statement is null.

if (m; std.regexp.search("abcdef", "b(c)d")) { writefln("Yippee!"); } else { writefln("Bad-ee."); } works already. (Replace "abcdef" with "abXdef" to see.)
Feb 27 2006
parent David Medlock <noone nowhere.com> writes:
Georg Wrede wrote:

 David Medlock wrote:
 
 Georg Wrede wrote:

 Better 'fess up front: the intent of this post is to once and for all 
 murder, pulverize and extradite the new if construct.

 Consider:

         if (m; std.regexp.search("abcdef", "b(c)d"))
         {
             writefln("[%s]", m.pre);      // prints [a]
             writefln("[%s]", m.post);     // prints [ef]
             writefln("[%s]", m.match(0)); // prints [bcd]
             writefln("[%s]", m.match(1)); // prints [c]
             writefln("[%s]", m.match(2)); // prints []
         }

 Flauting this around has shown that experienced programmers have a 
 hard time figuring out what is going on here.


 I would say extend the with(...) construct to silently fail( and take 
 an else clause ) if the object of the with statement is null.

if (m; std.regexp.search("abcdef", "b(c)d")) { writefln("Yippee!"); } else { writefln("Bad-ee."); } works already. (Replace "abcdef" with "abXdef" to see.)

It may work but you are making a new nest of corner cases with a known programming construct with specific behavior. Looks as if one mistyped semicolon could introduce very interesting behavior... -DavidM
Mar 02 2006
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Georg Wrede wrote:
 Better 'fess up front: the intent of this post is to once and for all 
 murder, pulverize and extradite the new if construct.
 
 Consider:
 
         if (m; std.regexp.search("abcdef", "b(c)d"))

 Now consider:
 
         if (Regexp m = std.regexp.search("abcdef", "b(c)d"))
         {
             writefln("[%s]", m.pre);      // prints [a]
             writefln("[%s]", m.post);     // prints [ef]
             writefln("[%s]", m.match(0)); // prints [bcd]
             writefln("[%s]", m.match(1)); // prints [c]
             writefln("[%s]", m.match(2)); // prints []
         }
 
 Flaunting this around (to both the original programmers, and also to 
 virgin victims), gave the same, _immediate_ comment from everybody: "Ah, 
 that's neat!"

It should be quite straightforward to support both syntaxes. People could have the choice of declaration syntax to match for, or semicolon syntax to match foreach. Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Feb 27 2006
prev sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
I'll vote against it because I don't understand the value of

if (m; search("abcdef", "BcdasdfD"))

over

if (Regexp m = search("abcdef", "BcdasdfD") ) .

Maybe someone can enlighten me?


Georg Wrede wrote:
 Better 'fess up front: the intent of this post is to once and for all 
 murder, pulverize and extradite the new if construct.
 
 Consider:
 
         if (m; std.regexp.search("abcdef", "b(c)d"))
         {
             writefln("[%s]", m.pre);      // prints [a]
             writefln("[%s]", m.post);     // prints [ef]
             writefln("[%s]", m.match(0)); // prints [bcd]
             writefln("[%s]", m.match(1)); // prints [c]
             writefln("[%s]", m.match(2)); // prints []
         }
 
 Flauting this around has shown that experienced programmers have a hard 
 time figuring out what is going on here.
 
 Consider:
 
         if (m; std.regexp.search("abcdef", "b(c)d"))
 
 Most everybody take it for granted that here is a typo, the '(m;' must 
 be the result of a sloppy copy-paste.
 
 And in the previous case the theories ranged from all kinds of 
 behind-the-scenes magic.
 
 Now consider:
 
         if (Regexp m = std.regexp.search("abcdef", "b(c)d"))
         {
             writefln("[%s]", m.pre);      // prints [a]
             writefln("[%s]", m.post);     // prints [ef]
             writefln("[%s]", m.match(0)); // prints [bcd]
             writefln("[%s]", m.match(1)); // prints [c]
             writefln("[%s]", m.match(2)); // prints []
         }
 
 Flaunting this around (to both the original programmers, and also to 
 virgin victims), gave the same, _immediate_ comment from everybody: "Ah, 
 that's neat!"

Feb 27 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"clayasaurus" <clayasaurus gmail.com> wrote in message 
news:dtvmkf$2e1a$1 digitaldaemon.com...
 I'll vote against it because I don't understand the value of

 if (m; search("abcdef", "BcdasdfD"))

 over

 if (Regexp m = search("abcdef", "BcdasdfD") ) .

 Maybe someone can enlighten me?

1) m is implicitly typed 2) looks like the foreach 3) more concise
Feb 28 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Tue, 28 Feb 2006 21:04:49 +1100, Walter Bright  
<newshound digitalmars.com> wrote:

 "clayasaurus" <clayasaurus gmail.com> wrote in message
 news:dtvmkf$2e1a$1 digitaldaemon.com...
 I'll vote against it because I don't understand the value of

 if (m; search("abcdef", "BcdasdfD"))

 over

 if (Regexp m = search("abcdef", "BcdasdfD") ) .

 Maybe someone can enlighten me?

1) m is implicitly typed 2) looks like the foreach 3) more concise

4) ugly (looks like C) 5) Walter's idea -- Derek Parnell Melbourne, Australia
Feb 28 2006
parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Derek Parnell wrote:
 On Tue, 28 Feb 2006 21:04:49 +1100, Walter Bright 
 <newshound digitalmars.com> wrote:
 
 "clayasaurus" <clayasaurus gmail.com> wrote in message
 news:dtvmkf$2e1a$1 digitaldaemon.com...
 I'll vote against it because I don't understand the value of

 if (m; search("abcdef", "BcdasdfD"))

 over

 if (Regexp m = search("abcdef", "BcdasdfD") ) .

 Maybe someone can enlighten me?

1) m is implicitly typed 2) looks like the foreach 3) more concise

4) ugly (looks like C) 5) Walter's idea

I think I too prefer: if (auto m = search("abcdef", "BcdasdfD") ) but don't support it 100%. Maybe there is a even better way out there.. -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Feb 28 2006
prev sibling next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Is it more concise to the maintainer if they are unfamiliar with the 
given type?

(in case of 'if (m; mystery())' maintainer will have to discover what 
mystery() returns instead of knowing it returns given 'type' right off 
the bat.

Might this negate any time saved in typing?

Walter Bright wrote:
 "clayasaurus" <clayasaurus gmail.com> wrote in message 
 news:dtvmkf$2e1a$1 digitaldaemon.com...
 I'll vote against it because I don't understand the value of

 if (m; search("abcdef", "BcdasdfD"))

 over

 if (Regexp m = search("abcdef", "BcdasdfD") ) .

 Maybe someone can enlighten me?

1) m is implicitly typed 2) looks like the foreach 3) more concise

Feb 28 2006
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
clayasaurus wrote:
 Is it more concise to the maintainer if they are unfamiliar with the
 given type?
 
 (in case of 'if (m; mystery())' maintainer will have to discover what
 mystery() returns instead of knowing it returns given 'type' right off
 the bat.
 
 Might this negate any time saved in typing?
 

That's very true. This kind of code isn't very self documenting. You have to search through the API (can take a lot of time) or just remember it somehow. In a huge class hierarchy this will be a major setback, what do you think?
Feb 28 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 "clayasaurus" <clayasaurus gmail.com> wrote in message 
 news:dtvmkf$2e1a$1 digitaldaemon.com...
 I'll vote against it because I don't understand the value of

 if (m; search("abcdef", "BcdasdfD"))

 over

 if (Regexp m = search("abcdef", "BcdasdfD") ) .

 Maybe someone can enlighten me?

1) m is implicitly typed 2) looks like the foreach 3) more concise

I've given this some thought and decided I don't see any value in: if( m; search( "", "" ) ) over: if( auto m = search( "", "" ) ) Both are implicitly typed and I feel the latter is more meaningful. It also has the arguable benefit of being consistent with C++. Also, I think the desire for with foreach is a red herring, as the meaning of foreach is entirely unique within D: "for each thing in this sequence, do something." That is, it's clear that a value or value/key pair must be assigned or the loop is meaningless. Contrast this with if, while, and even for loops whose purpose is condition evaluation (or perhaps counting in the case of a for loop) and the meaning of the declarative syntax present in foreach is much less clear. This also leaves 'for' as the odd man out, as I assume it's meaningless to do this: for( m; search( "", "" ); ) If this were legal I'd be tempted to suggest simply doing away with foreach entirely, which doesn't seem at all reasonable. So basically, I think that foreach is a special case and should be treated as such. While adding a type name (or 'auto') and an assignment may be a bit more verbose than the existing syntax, I think it benefits from being far more meaningful in expressions where such assignments are not necessary, and does not lose any flexibility over the current method. Sean
Mar 03 2006