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!"


  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.


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.


I second that; it would certainly make more sense.
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.




Hmm... now that I think about it, what about "autotype?"

 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.


 I second that; it would certainly make more sense.
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>).


 I'm just glad you didn't use this argument against array slicing ; )


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>).


 I'm just glad you didn't use this argument against array slicing ; )


 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>). 


I believe more people would associate "var" with modern languages like 

"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.
 


Now this is something I've been meaning to comment on but haven't yet. 
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>). 
 


It wouldn't be, because they do different things. And even if it were, 
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.


 Now this is something I've been meaning to comment on but haven't yet.
 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>).


 It wouldn't be, because they do different things. And even if it were,
 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:









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"))


<snip>

 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
 


Agreed that it's damn ugly, but don't see why it looks like C.

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