www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Changing the behavior of the comma operator

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
After the recent discussions regarding the comma operator, and after 
inspecting the patterns of code affected by it, Walter and I would back 
up the following change to the D language:

1. The comma operator stays with its current syntax.

2. The semantics is the same unless warnings are enabled with "-w"

3. In "-w" mode, semantics are changed in that the type of the comma 
operator is NOT the type of its last expression, but instead it's void.

4. Later on the warning will be promoted to a deprecation followed by 
removal from the language.

5. Reintroducing the result type as a tuple remains a future possibility.

We believe the change would be beneficial for the following reasons:

1. Based on druntime and phobos, the breakage is likely to be infrequent.

2. The change may catch (and has caught) important bugs caused by 
misplacing closing parentheses.

3. Most code using the result of the comma expression looks foreign even 
to seasoned programmers and might gain in clarity from a refactor.


Please reply to discuss this possibility.


Andrei
Mar 25 2014
next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 25 March 2014 at 17:33:20 UTC, Andrei Alexandrescu 
wrote:
 2. The change may catch (and has caught) important bugs caused 
 by misplacing closing parentheses.

 Andrei

I think it's worth it, if only for this.
Mar 25 2014
prev sibling next sibling parent reply "Asman01" <jckj33 gmail.com> writes:
On Tuesday, 25 March 2014 at 17:33:20 UTC, Andrei Alexandrescu 
wrote:
 After the recent discussions regarding the comma operator, and 
 after inspecting the patterns of code affected by it, Walter 
 and I would back up the following change to the D language:

 1. The comma operator stays with its current syntax.

 2. The semantics is the same unless warnings are enabled with 
 "-w"

 3. In "-w" mode, semantics are changed in that the type of the 
 comma operator is NOT the type of its last expression, but 
 instead it's void.

 4. Later on the warning will be promoted to a deprecation 
 followed by removal from the language.

 5. Reintroducing the result type as a tuple remains a future 
 possibility.

 We believe the change would be beneficial for the following 
 reasons:

 1. Based on druntime and phobos, the breakage is likely to be 
 infrequent.

 2. The change may catch (and has caught) important bugs caused 
 by misplacing closing parentheses.

 3. Most code using the result of the comma expression looks 
 foreign even to seasoned programmers and might gain in clarity 
 from a refactor.


 Please reply to discuss this possibility.


 Andrei

At first I throught didn't remove comma operator from language because it will make(possibly) hard to C/C++ guys porting code to D but instead of it will be allowed but return void type? why is this better than remove? but I'm happy this int a = 123,456; will give a type error instead of compile.
Mar 25 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/25/14, 10:45 AM, Asman01 wrote:
 On Tuesday, 25 March 2014 at 17:33:20 UTC, Andrei Alexandrescu wrote:
 After the recent discussions regarding the comma operator, and after
 inspecting the patterns of code affected by it, Walter and I would
 back up the following change to the D language:

 1. The comma operator stays with its current syntax.

 2. The semantics is the same unless warnings are enabled with "-w"

 3. In "-w" mode, semantics are changed in that the type of the comma
 operator is NOT the type of its last expression, but instead it's void.

 4. Later on the warning will be promoted to a deprecation followed by
 removal from the language.

 5. Reintroducing the result type as a tuple remains a future possibility.

 We believe the change would be beneficial for the following reasons:

 1. Based on druntime and phobos, the breakage is likely to be infrequent.

 2. The change may catch (and has caught) important bugs caused by
 misplacing closing parentheses.

 3. Most code using the result of the comma expression looks foreign
 even to seasoned programmers and might gain in clarity from a refactor.


 Please reply to discuss this possibility.


 Andrei

At first I throught didn't remove comma operator from language because it will make(possibly) hard to C/C++ guys porting code to D but instead of it will be allowed but return void type? why is this better than remove?

You are responding to the post replying all of these questions. Adnrei
Mar 25 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 25 March 2014 at 17:33:20 UTC, Andrei Alexandrescu 
wrote:
 After the recent discussions regarding the comma operator, and 
 after inspecting the patterns of code affected by it, Walter 
 and I would back up the following change to the D language:

 1. The comma operator stays with its current syntax.

 2. The semantics is the same unless warnings are enabled with 
 "-w"

 3. In "-w" mode, semantics are changed in that the type of the 
 comma operator is NOT the type of its last expression, but 
 instead it's void.

 4. Later on the warning will be promoted to a deprecation 
 followed by removal from the language.

 5. Reintroducing the result type as a tuple remains a future 
 possibility.

 We believe the change would be beneficial for the following 
 reasons:

 1. Based on druntime and phobos, the breakage is likely to be 
 infrequent.

 2. The change may catch (and has caught) important bugs caused 
 by misplacing closing parentheses.

 3. Most code using the result of the comma expression looks 
 foreign even to seasoned programmers and might gain in clarity 
 from a refactor.


 Please reply to discuss this possibility.


 Andrei

You are missing necessary step between (3) and (4) : making any usage of comma operator a warning. According to current language feature deprecation practices one cannot just go to a deprecation message omitting _exact same_ warning (judging by my observations, of course). This was why I have objected against this compromise initially - it only makes transition process more complicated if you are going to remove comma anyway and reduction in breakage feels questionable (unless I have missed some hard data). Still, full support for anything that removes comma expression completely in the end.
Mar 25 2014
prev sibling next sibling parent Kenji Hara <k.hara.pg gmail.com> writes:
--001a1134d616ca96aa04f572133b
Content-Type: text/plain; charset=UTF-8

2014-03-26 2:33 GMT+09:00 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org
:

 After the recent discussions regarding the comma operator, and after
 inspecting the patterns of code affected by it, Walter and I would back up
 the following change to the D language:

 1. The comma operator stays with its current syntax.

 2. The semantics is the same unless warnings are enabled with "-w"

 3. In "-w" mode, semantics are changed in that the type of the comma
 operator is NOT the type of its last expression, but instead it's void.

 4. Later on the warning will be promoted to a deprecation followed by
 removal from the language.

 5. Reintroducing the result type as a tuple remains a future possibility.

 We believe the change would be beneficial for the following reasons:

 1. Based on druntime and phobos, the breakage is likely to be infrequent.

 2. The change may catch (and has caught) important bugs caused by
 misplacing closing parentheses.

 3. Most code using the result of the comma expression looks foreign even
 to seasoned programmers and might gain in clarity from a refactor.


 Please reply to discuss this possibility.

Sounds good. Typing comma expressions as void would be a good way. Kenji Hara --001a1134d616ca96aa04f572133b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2014= -03-26 2:33 GMT+09:00 Andrei Alexandrescu <span dir=3D"ltr">&lt;<a href=3D"= mailto:SeeWebsiteForEmail erdani.org" target=3D"_blank">SeeWebsiteForEmail = erdani.org</a>&gt;</span>:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">After the recent discussions regarding the c= omma operator, and after inspecting the patterns of code affected by it, Wa= lter and I would back up the following change to the D language:<br> <br> 1. The comma operator stays with its current syntax.<br> <br> 2. The semantics is the same unless warnings are enabled with &quot;-w&quot= ;<br> <br> 3. In &quot;-w&quot; mode, semantics are changed in that the type of the co= mma operator is NOT the type of its last expression, but instead it&#39;s v= oid.<br> <br> 4. Later on the warning will be promoted to a deprecation followed by remov= al from the language.<br> <br> 5. Reintroducing the result type as a tuple remains a future possibility.<b= r> <br> We believe the change would be beneficial for the following reasons:<br> <br> 1. Based on druntime and phobos, the breakage is likely to be infrequent.<b= r> <br> 2. The change may catch (and has caught) important bugs caused by misplacin= g closing parentheses.<br> <br> 3. Most code using the result of the comma expression looks foreign even to= seasoned programmers and might gain in clarity from a refactor.<br> <br> <br> Please reply to discuss this possibility.</blockquote><div><br></div><div>S= ounds good. Typing comma expressions as void would be a good way.</div><div=
<br></div><div>Kenji Hara</div></div></div></div>

--001a1134d616ca96aa04f572133b--
Mar 25 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Please reply to discuss this possibility.

I think total removal of the comma operator could offer more readable D code. A counting of the answers from the precedent thread: Total removal: Asman01, deadalnix, Dicebot, John Colvin, Mike James, bearophile, Philpax, ponce, Simen Kjærås, Meta, Daniel Murphy, H. S. Teoh, Sean Kelly, ilya-stromberg. Neutral or slightly against removal: Adam D. Ruppe, Nick Treleaven. Partially against removal: Kenji Hara. OK with just removal of return: Andrei Alexandrescu, Meta, Daniel Murphy, deadalnix, John Colvin, perhaps Steven Schveighoffer. Do not like just the removal of return: Adam D. Ruppe, Brian Schott, Dicebot. I don't know the answers of: Andrej Mitrovic, Sarath Kodali, Don. Bye, bearophile
Mar 25 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/25/14, 10:58 AM, bearophile wrote:
 Andrei Alexandrescu:

 Please reply to discuss this possibility.

I think total removal of the comma operator could offer more readable D code. A counting of the answers from the precedent thread:

This is not a vote! Please discuss arguments, not headcount. Thanks! -- Andrei
Mar 25 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/26/14, 7:39 AM, Steven Schveighoffer wrote:
 On Wed, 26 Mar 2014 10:24:59 -0400, Kagamin <spam here.lot> wrote:

 On Wednesday, 26 March 2014 at 11:08:45 UTC, Andrej Mitrovic wrote:
 Have you never experienced this bug before?

 enum vals = [
     "afoo01foo01",
     "bbar02foo02",
     "cdoo03foo03",
     "dfoo01foo04",
     "ebar02foo01",
     "fdoo03foo02",
     "gfoo01foo03",
     "hbar02foo04",
     "aidoo03foo01"
     "jfoo01foo02a",
     "kbar02foo03",
     "ldoo03foo04",
 ];

In such case I add lines by copying other lines, so there's little chance to miss a comma. Well, I don't think you can find someone, who would defend implicit concatenation.

Frequently, I have situations where I do not put a comma on the last element.

Big mistake :o). -- Andrei
Mar 26 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/26/14, 10:34 AM, monarch_dodra wrote:
 On Wednesday, 26 March 2014 at 17:27:16 UTC, Andrei Alexandrescu wrote:
 Big mistake :o). -- Andrei

Yeah, how are we doing on that front? Have any decisions actually been made?

What front?
Mar 26 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/26/14, 10:51 AM, monarch_dodra wrote:
 On Wednesday, 26 March 2014 at 17:40:36 UTC, Andrei Alexandrescu wrote:
 On 3/26/14, 10:34 AM, monarch_dodra wrote:
 On Wednesday, 26 March 2014 at 17:27:16 UTC, Andrei Alexandrescu wrote:
 Big mistake :o). -- Andrei

Yeah, how are we doing on that front? Have any decisions actually been made?

What front?

The "Warn against and then deprecate implicit concatenation of adjacent string literals" issue: https://d.puremagic.com/issues/show_bug.cgi?id=3827 Yebblies seemed to have something going, since he submitted this: https://github.com/D-Programming-Language/phobos/pull/1871 I'm not up-to-date on the latest developments in dmd, so I'm asking if any decisions have been made about this?

I personally use the implicit concatenation on occasion and it doesn't trip me, but I wouldn't mind adding a ~. But in a way that's beside the point. I'd much rather make non-breaking improvements to the language, as there are plenty of opportunities. I feel changing string concatenation right now is just thinking small. Andrei
Mar 26 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/26/14, 11:36 AM, bearophile wrote:
 Fixing a little design mistake that causes bugs is not stopping all the
 other people like you from thinking about the more significant issues
 like concurrency, parallelism, reference scope, synchronized, and so on.

Doesn't seem like it. From where I stand, all these petty debates that last forever take focus away from a small team of core contributors. A dozen people are laying the bricks, whereas everybody else wrings their hands on the side and occasionally point out a spec of dust that's not where they think it should be.
 But in a way that's beside the point. I'd much rather make
 non-breaking improvements to the language, as there are plenty of
 opportunities.

I don't agree. It's much better to fix the little breaking changes now, and think about non-breaking improvements later. Because later the breaking changes will become less and less possible.

That later is already now. Andrei
Mar 26 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/26/2014 08:49 PM, Andrei Alexandrescu wrote:
 I don't agree. It's much better to fix the little breaking changes now,
 and think about non-breaking improvements later. Because later the
 breaking changes will become less and less possible.

That later is already now.

So how come there exists this thread on breaking the comma operator?
Mar 26 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/26/14, 3:13 PM, Timon Gehr wrote:
 On 03/26/2014 08:49 PM, Andrei Alexandrescu wrote:
 I don't agree. It's much better to fix the little breaking changes now,
 and think about non-breaking improvements later. Because later the
 breaking changes will become less and less possible.

That later is already now.

So how come there exists this thread on breaking the comma operator?

Because it's arguably worth it. -- Andrei
Mar 26 2014
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/26/2014 05:19 PM, H. S. Teoh wrote:
 	int x = 1, 5;	// hands up, how many understand what this does?

Nothing. This fails to parse because at that place ',' is expected to be a separator for declarators.
Mar 26 2014
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 25 Mar 2014 13:33:21 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 After the recent discussions regarding the comma operator, and after  
 inspecting the patterns of code affected by it, Walter and I would back  
 up the following change to the D language:

 1. The comma operator stays with its current syntax.

 2. The semantics is the same unless warnings are enabled with "-w"

 3. In "-w" mode, semantics are changed in that the type of the comma  
 operator is NOT the type of its last expression, but instead it's void.

 4. Later on the warning will be promoted to a deprecation followed by  
 removal from the language.

 5. Reintroducing the result type as a tuple remains a future possibility.

I think this should not be done. Note that even though code which is D could reintroduce commas safely, C code will still exist at that time, and likely need porting to D. The principle that C code should either do the same thing, or not compile, would be violated.
 1. Based on druntime and phobos, the breakage is likely to be infrequent.

 2. The change may catch (and has caught) important bugs caused by  
 misplacing closing parentheses.

 3. Most code using the result of the comma expression looks foreign even  
 to seasoned programmers and might gain in clarity from a refactor.

I agree with the change, up through step 4. I think the result of comma expression should *ALWAYS* be void. -Steve
Mar 25 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 3/26/2014 7:44 AM, "Marc Schütz" <schuetzm gmx.net>" wrote:
 On Tuesday, 25 March 2014 at 19:25:43 UTC, ixid wrote:
 I think this should not be done. Note that even though code which is
 D could reintroduce commas safely, C code will still exist at that
 time, and likely need porting to D. The principle that C code should
 either do the same thing, or not compile, would be violated.

What would be an example of C code that would compile in a D where the comma operator was used for tuples? Also why is cut and pasting C code to D so important? If it's non-trivial surely people will just use extern C. If it's trivial they can make the minor improvements necessary.

This is valid in both C and C++: i, j = 0, 1; It is equivalent to the following: i; j = 0; 1;

Under the proposal, the "0, 1" would be void, so it wouldn't compile in D. Therefore, the rule about moving C code to D safely is not violated.
Mar 26 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
 Partially against removal: Kenji Hara.

There is also etcimon against the removal of the comma. And Kenji Hara is OK with just removing the return. Bye, bearophile
Mar 25 2014
prev sibling next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Tuesday, 25 March 2014 at 17:33:20 UTC, Andrei Alexandrescu 
wrote:
 After the recent discussions regarding the comma operator, and 
 after inspecting the patterns of code affected by it, Walter 
 and I would back up the following change to the D language:

 1. The comma operator stays with its current syntax.

 2. The semantics is the same unless warnings are enabled with 
 "-w"

 3. In "-w" mode, semantics are changed in that the type of the 
 comma operator is NOT the type of its last expression, but 
 instead it's void.

 4. Later on the warning will be promoted to a deprecation 
 followed by removal from the language.

 5. Reintroducing the result type as a tuple remains a future 
 possibility.

 We believe the change would be beneficial for the following 
 reasons:

 1. Based on druntime and phobos, the breakage is likely to be 
 infrequent.

 2. The change may catch (and has caught) important bugs caused 
 by misplacing closing parentheses.

 3. Most code using the result of the comma expression looks 
 foreign even to seasoned programmers and might gain in clarity 
 from a refactor.


 Please reply to discuss this possibility.


 Andrei

Having the comma expression return void is a pretty clever way of disallowing most of its buggy usage. You mentioned in the other thread that we are looking at 5 years or more before the comma operator can be used in tuple expressions. Is that timeline still accurate with these proposed changes?
Mar 25 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/25/14, 11:33 AM, Meta wrote:
 Having the comma expression return void is a pretty clever way of
 disallowing most of its buggy usage. You mentioned in the other thread
 that we are looking at 5 years or more before the comma operator can be
 used in tuple expressions. Is that timeline still accurate with these
 proposed changes?

I'm afraid so. But that's the case regardless. Andrei
Mar 25 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/28/14, 2:15 AM, bearophile wrote:
 Kagamin:

 The problem with tuples is not syntax, but semantics: DIP32 should
 specify, when automatic unpacking happens and when doesn't, that's a
 very sloppy feature, so it should be specified better.

OK. (But from the last posts on the topic Andrei seems unfit to design D tuples).

Where did that one come from? Oh boy. Andrei
Mar 28 2014
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 25, 2014 at 10:33:21AM -0700, Andrei Alexandrescu wrote:
 After the recent discussions regarding the comma operator, and after
 inspecting the patterns of code affected by it, Walter and I would
 back up the following change to the D language:
 
 1. The comma operator stays with its current syntax.
 
 2. The semantics is the same unless warnings are enabled with "-w"
 
 3. In "-w" mode, semantics are changed in that the type of the comma
 operator is NOT the type of its last expression, but instead it's void.

I think you're missing a step here. Shouldn't "-w" be promoted to a by-default warning first, before becoming a full deprecation?
 4. Later on the warning will be promoted to a deprecation followed by
 removal from the language.

Yay!
 5. Reintroducing the result type as a tuple remains a future possibility.

Yay!
 We believe the change would be beneficial for the following reasons:
 
 1. Based on druntime and phobos, the breakage is likely to be infrequent.

I concur.
 2. The change may catch (and has caught) important bugs caused by
 misplacing closing parentheses.

I think this is a very big plus for removing the comma operator. As I've said before in the other thread on this topic, I doubt if a significant number of D coders even understand what a comma operator *is*, let alone its subtle semantics. This in itself already indicates that it's a minefield waiting to blow up. Those who *do* know what it is may not necessarily know all the fine details of its tricky behaviour, and indeed, as you point out, bugs have been introduced because of this. And finally:
 3. Most code using the result of the comma expression looks foreign
 even to seasoned programmers and might gain in clarity from a
 refactor.

Absolutely. I used to write IOCCC entries, for crying out loud, and I still find the comma operator to be a net minus. :P (Well, they're a net plus if you're trying to obfuscate your code, but presumably this only applies to IOCCC entries. :P) Well, that, and also C++ libraries that overload the comma operator to do counter-intuitive things like this: Array<double, 2> matrix; matrix = 1, 2, 3, 4, 5, 6, 7, 8, 9; It looks all cool and everything, until you realize the horrible, horrible, readability problems that arise: Array<double, 2> matrix; matrix = 1, 2, 3, 4, 5, 6, 7, 8, 9; // huh? matrix = 1, 2, 3, 4, 5, 6, 7, 8, 9; // wat? matrix = (1,2), (flag ? 3 : 4), 5, 6, 7, (flag2 ? 8 : (x,10)), 9; // argh my head hurtz... The comma operator definitely causes a lot of readability problems, and while some people may object to its removal, I think in the long run it will be a net plus, because it forces people to write code that others understand(!). In this day and age, one-man projects are basically a thing of the past, and issues like readability and maintainability are very important factors. D's readability over C++ is a big selling point, and we should leverage that. T -- Designer clothes: how to cover less by paying more.
Mar 25 2014
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/25/2014 07:52 PM, H. S. Teoh wrote:
 I doubt if a significant
 number of D coders even understand what a comma operator*is*, let alone
 its subtle semantics. This in itself already indicates that it's a
 minefield waiting to blow up. Those who*do*  know what it is may not
 necessarily know all the fine details of its tricky behaviour,

What 'subtle semantics' or 'tricky behaviour'? It is straightforward. The introduced bugs are due to accidental usage caused by failure to match parentheses correctly. (i.e. comma removes some redundancy from the language syntax. This does not mean it is a difficult concept.)
Mar 25 2014
prev sibling next sibling parent "ixid" <nuaccount gmail.com> writes:
 I think this should not be done. Note that even though code 
 which is D could reintroduce commas safely, C code will still 
 exist at that time, and likely need porting to D. The principle 
 that C code should either do the same thing, or not compile, 
 would be violated.

What would be an example of C code that would compile in a D where the comma operator was used for tuples? Also why is cut and pasting C code to D so important? If it's non-trivial surely people will just use extern C. If it's trivial they can make the minor improvements necessary.
Mar 25 2014
prev sibling next sibling parent reply captaindet <2krnk gmx.net> writes:
On 2014-03-25 12:33, Andrei Alexandrescu wrote:
 After the recent discussions regarding the comma operator, and after
 inspecting the patterns of code affected by it, Walter and I would
 back up the following change to the D language:

 1. The comma operator stays with its current syntax.

 2. The semantics is the same unless warnings are enabled with "-w"

 3. In "-w" mode, semantics are changed in that the type of the comma
 operator is NOT the type of its last expression, but instead it's
 void.

 4. Later on the warning will be promoted to a deprecation followed by
 removal from the language.

mwould this effect comma usage inside for-loops as well or will this be special cased? i would not like to see it go from for-loops. i don't mind otherwise. /det
Mar 25 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/25/14, 12:29 PM, captaindet wrote:
 mwould this effect comma usage inside for-loops as well or will this be
 special cased?

Where inside for loops? -- Andrei
Mar 25 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/25/14, 4:08 PM, H. S. Teoh wrote:
 On Tue, Mar 25, 2014 at 12:45:26PM -0700, Andrei Alexandrescu wrote:
 On 3/25/14, 12:29 PM, captaindet wrote:
 mwould this effect comma usage inside for-loops as well or will this be
 special cased?

Where inside for loops? -- Andrei

for (x=1, y=2; x < 10 && y < 20; x++, y++) { ... } My opinion is to just special-case the syntax for for-loops.

The proposed change would allow the code above, but not this: for (x=1, y=2; x++, x < 10 && y < 20; y++) { ... } Andrei
Mar 25 2014
parent simendsjo <simendsjo gmail.com> writes:
On 03/26/2014 10:19 AM, Jason King wrote:
 The proposed change would allow the code above, but not this:

 for (x=1, y=2; x++, x < 10 && y < 20; y++) { ... }


 Andrei

After the change in D this code would generate a warning/error? If that's so then the "does the same as C code or fails to compile" objective is still being met.

(x++, x < 10) would be a void rather than bool if I understand correctly, so this wouldn't compile.
Mar 26 2014
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 25, 2014 at 12:45:26PM -0700, Andrei Alexandrescu wrote:
 On 3/25/14, 12:29 PM, captaindet wrote:
mwould this effect comma usage inside for-loops as well or will this be
special cased?

Where inside for loops? -- Andrei

for (x=1, y=2; x < 10 && y < 20; x++, y++) { ... } My opinion is to just special-case the syntax for for-loops. T -- Unix is my IDE. -- Justin Whear
Mar 25 2014
prev sibling next sibling parent "Asman01" <jckj33 gmail.com> writes:
On Tuesday, 25 March 2014 at 23:16:32 UTC, Andrei Alexandrescu 
wrote:
 On 3/25/14, 4:08 PM, H. S. Teoh wrote:
 On Tue, Mar 25, 2014 at 12:45:26PM -0700, Andrei Alexandrescu 
 wrote:
 On 3/25/14, 12:29 PM, captaindet wrote:
 mwould this effect comma usage inside for-loops as well or 
 will this be
 special cased?

Where inside for loops? -- Andrei

for (x=1, y=2; x < 10 && y < 20; x++, y++) { ... } My opinion is to just special-case the syntax for for-loops.

The proposed change would allow the code above, but not this: for (x=1, y=2; x++, x < 10 && y < 20; y++) { ... } Andrei

What term should we design to this type of expression? r-value?
Mar 25 2014
prev sibling parent "Jason King" <jhking airmail.net> writes:
 The proposed change would allow the code above, but not this:

 for (x=1, y=2; x++, x < 10 && y < 20; y++) { ... }


 Andrei

After the change in D this code would generate a warning/error? If that's so then the "does the same as C code or fails to compile" objective is still being met.
Mar 26 2014
prev sibling next sibling parent "ixid" <nuaccount gmail.com> writes:
On Tuesday, 25 March 2014 at 19:09:01 UTC, Andrei Alexandrescu 
wrote:
 On 3/25/14, 11:33 AM, Meta wrote:
 Having the comma expression return void is a pretty clever way 
 of
 disallowing most of its buggy usage. You mentioned in the 
 other thread
 that we are looking at 5 years or more before the comma 
 operator can be
 used in tuple expressions. Is that timeline still accurate 
 with these
 proposed changes?

I'm afraid so. But that's the case regardless. Andrei

Does this also mean a proper tuple syntax on a par with Go's is going to wait for five years? That seems too long for what should be a major feature and would suggest it should be done with something other than the comma operator.
Mar 25 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
ixid:

 Does this also mean a proper tuple syntax on a par with Go's is 
 going to wait for five years? That seems too long for what 
 should be a major feature and would suggest it should be done 
 with something other than the comma operator.

I think commas should not be used in ways that have a different semantics in C. So I think D tuples should have a syntax that uses comma operator like that. In the precedent thread Andrei has shown a ugly syntax to manage tuples. Bye, bearophile
Mar 25 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 25 Mar 2014 15:25:42 -0400, ixid <nuaccount gmail.com> wrote:

 I think this should not be done. Note that even though code which is D  
 could reintroduce commas safely, C code will still exist at that time,  
 and likely need porting to D. The principle that C code should either  
 do the same thing, or not compile, would be violated.

What would be an example of C code that would compile in a D where the comma operator was used for tuples? Also why is cut and pasting C code to D so important? If it's non-trivial surely people will just use extern C. If it's trivial they can make the minor improvements necessary.

It's not so much that it's important that it works, it's important that if it does work, it does the same thing. Why? Because it's a stated goal of D. We want to be able to easily port C code to D, without having silent errors. I don't have examples, I don't use the comma operator for anything except for loops. If there are no cases of legitimate C code that would compile incorrectly in D, then my objection is not valid. In either case, I'm fine with the proposal up to step 4. Changing the result of a comma expression later would be debated at the time we wanted to introduce it again, and that is going to be a long time in the future, there is no rush. -Steve
Mar 25 2014
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 25 March 2014 at 22:38:27 UTC, Timon Gehr wrote:
 What 'subtle semantics' or 'tricky behaviour'? It is 
 straightforward. The introduced bugs are due to accidental 
 usage caused by failure to match parentheses correctly. (i.e. 
 comma removes some redundancy from the language syntax. This 
 does not mean it is a difficult concept.)

I don't know about 'subtle semantics' or 'tricky behaviour'. It's not a difficult concept either, if you are willing to learn it. But it *is* one of the more "obscure" concepts. Most "average" coders could spend an entire career and never care nor know the damn thing is actually an operator.
Mar 25 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Tuesday, 25 March 2014 at 17:58:45 UTC, bearophile wrote:
 I think total removal of the comma operator could offer more 
 readable D code.

No, complete removal will make code less readable. Why can't you read commas?
Mar 26 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Kagamin:

 No, complete removal will make code less readable.

Why? Can you show examples?
 Why can't you read commas?

When I read code quickly I sometimes mistake what's the what part of the expression returned. C commas don't have a straightforward meaning. Bye, bearophile
Mar 26 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/26/14, Kagamin <spam here.lot> wrote:
 On Tuesday, 25 March 2014 at 17:58:45 UTC, bearophile wrote:
 I think total removal of the comma operator could offer more
 readable D code.

No, complete removal will make code less readable. Why can't you read commas?

Have you never experienced this bug before? enum vals = [ "afoo01foo01", "bbar02foo02", "cdoo03foo03", "dfoo01foo04", "ebar02foo01", "fdoo03foo02", "gfoo01foo03", "hbar02foo04", "aidoo03foo01" "jfoo01foo02a", "kbar02foo03", "ldoo03foo04", ]; This has nothing to do with the comma operator, but what it has to do is with readability. The comma is easily misplaced.
Mar 26 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:

 Have you never experienced this bug before?

 enum vals = [
     "afoo01foo01",
     "bbar02foo02",
     "cdoo03foo03",
     "dfoo01foo04",
     "ebar02foo01",
     "fdoo03foo02",
     "gfoo01foo03",
     "hbar02foo04",
     "aidoo03foo01"
     "jfoo01foo02a",
     "kbar02foo03",
     "ldoo03foo04",
 ];

Walter kind of agreed to remove that bug from D, but so far nothing has changed: https://d.puremagic.com/issues/show_bug.cgi?id=3827 Bye, bearophile
Mar 26 2014
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 26 March 2014 at 11:08:45 UTC, Andrej Mitrovic 
wrote:
 On 3/26/14, Kagamin <spam here.lot> wrote:
 On Tuesday, 25 March 2014 at 17:58:45 UTC, bearophile wrote:
 I think total removal of the comma operator could offer more
 readable D code.

No, complete removal will make code less readable. Why can't you read commas?

Have you never experienced this bug before? enum vals = [ "afoo01foo01", "bbar02foo02", "cdoo03foo03", "dfoo01foo04", "ebar02foo01", "fdoo03foo02", "gfoo01foo03", "hbar02foo04", "aidoo03foo01" "jfoo01foo02a", "kbar02foo03", "ldoo03foo04", ]; This has nothing to do with the comma operator, but what it has to do is with readability. The comma is easily misplaced.

I experienced it this very morning, testing your getopt code :/ Forgot to place the parens at all : string[] args = ["myProgram.exe" "--users" "foo" "bar"]; I know the code is wrong, but there's something that seriously pisses me off about code that compiles anyways, then does weird stuff. Implicit string concatenation brings *no* "functional" gains, but *is* a source of bugs. That should also killed with extreme prejudice.
Mar 26 2014
prev sibling next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Tuesday, 25 March 2014 at 19:25:43 UTC, ixid wrote:
 I think this should not be done. Note that even though code 
 which is D could reintroduce commas safely, C code will still 
 exist at that time, and likely need porting to D. The 
 principle that C code should either do the same thing, or not 
 compile, would be violated.

What would be an example of C code that would compile in a D where the comma operator was used for tuples? Also why is cut and pasting C code to D so important? If it's non-trivial surely people will just use extern C. If it's trivial they can make the minor improvements necessary.

This is valid in both C and C++: i, j = 0, 1; It is equivalent to the following: i; j = 0; 1; There might be more complex examples in C++ however, which allows more complex L-value expressions. This is invalid C, but valid C++: (i, j) = (0, 1); In C++, it is equivalent to: j = 1;
Mar 26 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Wednesday, 26 March 2014 at 10:54:44 UTC, bearophile wrote:
 When I read code quickly I sometimes mistake what's the what 
 part of the expression returned.

With this proposal an attempt to return the result of the comma operator won't compile.
Mar 26 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Wednesday, 26 March 2014 at 11:08:45 UTC, Andrej Mitrovic 
wrote:
 Have you never experienced this bug before?

 enum vals = [
     "afoo01foo01",
     "bbar02foo02",
     "cdoo03foo03",
     "dfoo01foo04",
     "ebar02foo01",
     "fdoo03foo02",
     "gfoo01foo03",
     "hbar02foo04",
     "aidoo03foo01"
     "jfoo01foo02a",
     "kbar02foo03",
     "ldoo03foo04",
 ];

In such case I add lines by copying other lines, so there's little chance to miss a comma. Well, I don't think you can find someone, who would defend implicit concatenation.
Mar 26 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 26 Mar 2014 10:24:59 -0400, Kagamin <spam here.lot> wrote:

 On Wednesday, 26 March 2014 at 11:08:45 UTC, Andrej Mitrovic wrote:
 Have you never experienced this bug before?

 enum vals = [
     "afoo01foo01",
     "bbar02foo02",
     "cdoo03foo03",
     "dfoo01foo04",
     "ebar02foo01",
     "fdoo03foo02",
     "gfoo01foo03",
     "hbar02foo04",
     "aidoo03foo01"
     "jfoo01foo02a",
     "kbar02foo03",
     "ldoo03foo04",
 ];

In such case I add lines by copying other lines, so there's little chance to miss a comma. Well, I don't think you can find someone, who would defend implicit concatenation.

Frequently, I have situations where I do not put a comma on the last element. Then via cut and paste, it is moved up without adding a comma, or you add more elements without adding the comma. Considering we have a concatenation operator, with constant folding, and we don't have the c preprocessor to deal with, we should kill this with fire. -Steve
Mar 26 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Wednesday, 26 March 2014 at 14:39:11 UTC, Steven Schveighoffer 
wrote:
 Frequently, I have situations where I do not put a comma on the 
 last element.

Hehe, I don't use features which I can't afford (e.g. template black magic). Otherwise I won't be able to handle my own code.
Mar 26 2014
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Mar 26, 2014 at 08:24:23AM +0000, Kagamin wrote:
 On Tuesday, 25 March 2014 at 17:58:45 UTC, bearophile wrote:
I think total removal of the comma operator could offer more readable
D code.

No, complete removal will make code less readable. Why can't you read commas?

Are you talking about the comma *operator*, or are you talking about commas in general? Please don't confuse the two. OTOH, the fact that people don't even understand what the comma operator is, is a good reason to kill it. With extreme prejudice. And for the sake of those who aren't clear: the comma operator has NOTHING to do with the following: int x,y; int[] a = [1,2,3]; func(a,x,y); enum E { A, B, C } So relax. We're not proposing to get rid of the comma in the whole language. What we're proposing is to get rid of things like this: int x = 1, 5; // hands up, how many understand what this does? T -- Leather is waterproof. Ever see a cow with an umbrella?
Mar 26 2014
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 26 March 2014 at 17:27:16 UTC, Andrei Alexandrescu 
wrote:
 Big mistake :o). -- Andrei

Yeah, how are we doing on that front? Have any decisions actually been made?
Mar 26 2014
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 26 March 2014 at 17:40:36 UTC, Andrei Alexandrescu 
wrote:
 On 3/26/14, 10:34 AM, monarch_dodra wrote:
 On Wednesday, 26 March 2014 at 17:27:16 UTC, Andrei 
 Alexandrescu wrote:
 Big mistake :o). -- Andrei

Yeah, how are we doing on that front? Have any decisions actually been made?

What front?

The "Warn against and then deprecate implicit concatenation of adjacent string literals" issue: https://d.puremagic.com/issues/show_bug.cgi?id=3827 Yebblies seemed to have something going, since he submitted this: https://github.com/D-Programming-Language/phobos/pull/1871 I'm not up-to-date on the latest developments in dmd, so I'm asking if any decisions have been made about this?
Mar 26 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 I personally use the implicit concatenation on occasion and it 
 doesn't trip me, but I wouldn't mind adding a ~.

While it's not a very common bug, it has tripped me few times. This is where I raised the issue in 2010: https://d.puremagic.com/issues/show_bug.cgi?id=3827 Walter agreed to remove it: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=121830
 I feel changing string concatenation right now is just thinking 
 small.

Fixing a little design mistake that causes bugs is not stopping all the other people like you from thinking about the more significant issues like concurrency, parallelism, reference scope, synchronized, and so on. Probably 80% of the bugs in Bugzilla are about very small things, like a missing assert, a wrong error message, or even wrong words used in documentation. Fixing those things is useful. Just because a problem is waiting for a fix in Bugzilla for years can't justify to close it down. In Bugzilla there are some other little breaking changes waiting to happen. There are operator precedence-related problems caused by replacing the implicit concatenation with a ~.
 But in a way that's beside the point. I'd much rather make 
 non-breaking improvements to the language, as there are plenty 
 of opportunities.

I don't agree. It's much better to fix the little breaking changes now, and think about non-breaking improvements later. Because later the breaking changes will become less and less possible. Bye, bearophile
Mar 26 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 I'd much rather make non-breaking improvements to the
 language, as there are plenty of opportunities.

Three improvements I'd like for D: - A not ugly and handy syntax for tuples; - Optionally strongly typed array indexes; - "enum preconditions" or something similar. The first helps me write functional code without doing contortions. The second is something I miss from Delphi/Ada and helps write medium integrity code with more safety. The third avoids some run-time bugs. Bye, bearophile
Mar 26 2014
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
On Wednesday, 26 March 2014 at 11:08:45 UTC, Andrej Mitrovic 
wrote:
 On 3/26/14, Kagamin <spam here.lot> wrote:
 On Tuesday, 25 March 2014 at 17:58:45 UTC, bearophile wrote:
 I think total removal of the comma operator could offer more
 readable D code.

No, complete removal will make code less readable. Why can't you read commas?

Have you never experienced this bug before? enum vals = [ "afoo01foo01", "bbar02foo02", "cdoo03foo03", "dfoo01foo04", "ebar02foo01", "fdoo03foo02", "gfoo01foo03", "hbar02foo04", "aidoo03foo01" "jfoo01foo02a", "kbar02foo03", "ldoo03foo04", ]; This has nothing to do with the comma operator, but what it has to do is with readability. The comma is easily misplaced.

I have done that so many times in Python. It's much harder to catch in Python too, due to dynamic typing.
Mar 26 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 26 March 2014 at 23:00:29 UTC, Andrei Alexandrescu
wrote:
 On 3/26/14, 3:13 PM, Timon Gehr wrote:
 On 03/26/2014 08:49 PM, Andrei Alexandrescu wrote:
 I don't agree. It's much better to fix the little breaking 
 changes now,
 and think about non-breaking improvements later. Because 
 later the
 breaking changes will become less and less possible.

That later is already now.

So how come there exists this thread on breaking the comma operator?

Because it's arguably worth it. -- Andrei

Because it has been agreed a long time a ago, but now we are backpedaling because we can't break code as much as we used to. That being said, I'm quite satisfied with Andrei's void return value proposal.
Mar 26 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 26 Mar 2014 17:32:00 -0400, Nick Sabalausky  =

<SeeWebsiteToContactMe semitwist.com> wrote:

 On 3/26/2014 7:44 AM, "Marc Sch=C3=BCtz" <schuetzm gmx.net>" wrote:
 This is valid in both C and C++:

    i, j =3D 0, 1;

 It is equivalent to the following:

    i;
    j =3D 0;
    1;

Under the proposal, the "0, 1" would be void, so it wouldn't compile i=

 D. Therefore, the rule about moving C code to D safely is not violated=


This part of the subthread is about the future plans to possibly use com= ma = operators to mean tuples. This C/C++ code will still be valid then, and = = when someone ports to D, might get a nasty silently compiling surprise. But, I think the proposal to re-introduce ',' as a tuple operator would = = not affect this code, it would remain a 3-element tuple, with i, j, 1 as= = elements (after setting j to 0 of course). '=3D' has precedence over ','= . The second statement would be a problem (i, j) =3D (0, 1), but clearly, = this = would not be a valid use case. I can envision there may be some valid us= e = cases of that form, however. -Steve
Mar 26 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 26 Mar 2014 13:27:17 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 3/26/14, 7:39 AM, Steven Schveighoffer wrote:

 Frequently, I have situations where I do not put a comma on the last
 element.

Big mistake :o). -- Andrei

A trailing comma in a list looks so wrong to me :) It looks like an unfinished declaration. I just as frequently have trailing commas because I delete the last element and forget to remove the comma on the "new" last element :D -Steve
Mar 26 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 27 March 2014 at 02:08:50 UTC, Steven Schveighoffer 
wrote:
 On Wed, 26 Mar 2014 17:32:00 -0400, Nick Sabalausky 
 <SeeWebsiteToContactMe semitwist.com> wrote:

 On 3/26/2014 7:44 AM, "Marc Schütz" <schuetzm gmx.net>" wrote:
 This is valid in both C and C++:

   i, j = 0, 1;

 It is equivalent to the following:

   i;
   j = 0;
   1;

Under the proposal, the "0, 1" would be void, so it wouldn't compile in D. Therefore, the rule about moving C code to D safely is not violated.

This part of the subthread is about the future plans to possibly use comma operators to mean tuples. This C/C++ code will still be valid then, and when someone ports to D, might get a nasty silently compiling surprise. But, I think the proposal to re-introduce ',' as a tuple operator would not affect this code, it would remain a 3-element tuple, with i, j, 1 as elements (after setting j to 0 of course). '=' has precedence over ','. The second statement would be a problem (i, j) = (0, 1), but clearly, this would not be a valid use case. I can envision there may be some valid use cases of that form, however. -Steve

I think you get operator priority wrong and it will be (i), (j = 0), (1). I added extra () to show how operator priority works.
Mar 26 2014
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Wed, 26 Mar 2014 22:02:44 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 03/26/2014 05:19 PM, H. S. Teoh wrote:
 	int x = 1, 5;	// hands up, how many understand what this does?

Nothing. This fails to parse because at that place ',' is expected to be a separator for declarators.

Spectacularly proving his point :p R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Mar 27 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Wednesday, 26 March 2014 at 16:21:01 UTC, H. S. Teoh wrote:
 What we're proposing is to get rid of things like this:

 	int x = 1, 5;	// hands up, how many understand what this does?

This proposal gets rid of this while keeping the comma operator.
Mar 27 2014
prev sibling next sibling parent "ed" <growlercab gmail.com> writes:
On Thursday, 27 March 2014 at 11:32:45 UTC, Kagamin wrote:
 On Wednesday, 26 March 2014 at 16:21:01 UTC, H. S. Teoh wrote:
 What we're proposing is to get rid of things like this:

 	int x = 1, 5;	// hands up, how many understand what this does?

This proposal gets rid of this while keeping the comma operator.

+1 to dropping to comma operator. This is what I would like to see illegal, forcing a refactor of code: if (((vertex= null), same.vertices)) for (blah){} Every time it catches me out and I misread the code to be: if(vertex == null && same.vertices) for (blah) {} Cheers, ed
Mar 27 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 27 March 2014 at 10:39:58 UTC, Regan Heath wrote:
 On Wed, 26 Mar 2014 22:02:44 -0000, Timon Gehr 
 <timon.gehr gmx.ch> wrote:

 On 03/26/2014 05:19 PM, H. S. Teoh wrote:
 	int x = 1, 5;	// hands up, how many understand what this 
 does?

Nothing. This fails to parse because at that place ',' is expected to be a separator for declarators.

Spectacularly proving his point :p

Did he want to kill the declaration statement too?
Mar 27 2014
prev sibling next sibling parent "ed" <growlercab gmail.com> writes:
On Thursday, 27 March 2014 at 11:43:36 UTC, ed wrote:
 On Thursday, 27 March 2014 at 11:32:45 UTC, Kagamin wrote:
 On Wednesday, 26 March 2014 at 16:21:01 UTC, H. S. Teoh wrote:
 What we're proposing is to get rid of things like this:

 	int x = 1, 5;	// hands up, how many understand what this 
 does?

This proposal gets rid of this while keeping the comma operator.

+1 to dropping to comma operator. This is what I would like to see illegal, forcing a refactor of code: if (((vertex= null), same.vertices)) for (blah){} Every time it catches me out and I misread the code to be: if(vertex == null && same.vertices) for (blah) {} Cheers, ed

s/== null/is null/
Mar 27 2014
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 27 March 2014 at 11:32:45 UTC, Kagamin wrote:
 On Wednesday, 26 March 2014 at 16:21:01 UTC, H. S. Teoh wrote:
 What we're proposing is to get rid of things like this:

 	int x = 1, 5;	// hands up, how many understand what this does?

This proposal gets rid of this while keeping the comma operator.

The point is that this is not the comma operator, and is already illegal to begin with. *This* is what is being made illegal int x = (1, 5); The point being that most programmers don't actually understand all the subtleties of comma operator vs argument listing. Mysielf included (I also thought that was a comma operator...) Also, not to mention issues with things like operator precedence... a = 1, 5 + 2; //What's a? a = (1 + 2, 5); //What's a? Speaking of which: a = 1, 5 + 2; Why doesn't dmd emit an "operator , has no effect" error? Or a = (1 + 2, 5) Why doesn't dmd emit an "operator + has no effect" error?
Mar 27 2014
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Thu, 27 Mar 2014 11:45:50 -0000, Kagamin <spam here.lot> wrote:

 On Thursday, 27 March 2014 at 10:39:58 UTC, Regan Heath wrote:
 On Wed, 26 Mar 2014 22:02:44 -0000, Timon Gehr <timon.gehr gmx.ch>  
 wrote:

 On 03/26/2014 05:19 PM, H. S. Teoh wrote:
 	int x = 1, 5;	// hands up, how many understand what this does?

Nothing. This fails to parse because at that place ',' is expected to be a separator for declarators.

Spectacularly proving his point :p

Did he want to kill the declaration statement too?

No. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Mar 27 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 27 Mar 2014 00:35:38 -0400, deadalnix <deadalnix gmail.com> wrot=
e:

 On Thursday, 27 March 2014 at 02:08:50 UTC, Steven Schveighoffer wrote=

 On Wed, 26 Mar 2014 17:32:00 -0400, Nick Sabalausky  =


 <SeeWebsiteToContactMe semitwist.com> wrote:

 On 3/26/2014 7:44 AM, "Marc Sch=C3=BCtz" <schuetzm gmx.net>" wrote:
 This is valid in both C and C++:

   i, j =3D 0, 1;

 It is equivalent to the following:

   i;
   j =3D 0;
   1;




 '=3D' has precedence over ','.

I think you get operator priority wrong and it will be (i), (j =3D 0),=

 (1). I added extra () to show how operator priority works.

I think that's what I said, no? -Steve
Mar 27 2014
prev sibling next sibling parent "Martin Nowak" <code dawg.eu> writes:
On Tuesday, 25 March 2014 at 17:33:20 UTC, Andrei Alexandrescu
wrote:
 2. The semantics is the same unless warnings are enabled with 
 "-w"

 3. In "-w" mode, semantics are changed in that the type of the 
 comma operator is NOT the type of its last expression, but 
 instead it's void.

 4. Later on the warning will be promoted to a deprecation 
 followed by removal from the language.

Semantic changes based on warning or deprecation flags are a bad idea, because it breaks code unless warnings are disabled. The cycle should go warning => deprecation => semantic change/removal, each step taking 6 month.
Mar 27 2014
prev sibling next sibling parent "Martin Nowak" <code dawg.eu> writes:
On Tuesday, 25 March 2014 at 19:09:01 UTC, Andrei Alexandrescu 
wrote:
 You mentioned in the other thread
 that we are looking at 5 years or more before the comma 
 operator can be
 used in tuple expressions. Is that timeline still accurate 
 with these
 proposed changes?

I'm afraid so. But that's the case regardless.

Sounds like a terrible idea as tuples are such an important tool in a modern programming language. It also seems unnecessary because there are many syntax alternatives. In fact a syntax decision would be the missing ingredient to get http://wiki.dlang.org/DIP32 rolling.
Mar 27 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Friday, 28 March 2014 at 02:21:11 UTC, Martin Nowak wrote:
 Sounds like a terrible idea as tuples are such an important 
 tool in a modern programming language.
 It also seems unnecessary because there are many syntax 
 alternatives. In fact a syntax decision would be the missing 
 ingredient to get http://wiki.dlang.org/DIP32 rolling.

The problem with tuples is not syntax, but semantics: DIP32 should specify, when automatic unpacking happens and when doesn't, that's a very sloppy feature, so it should be specified better. Other corner cases I can think about: is one-element tuple equivalent to that one element, is array literal a tuple, is string literal a tuple, how to infer packed and unpacked tuples, how to remember all these subtle features?
Mar 28 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Kagamin:

 The problem with tuples is not syntax, but semantics: DIP32 
 should specify, when automatic unpacking happens and when 
 doesn't, that's a very sloppy feature, so it should be 
 specified better.

OK. (But from the last posts on the topic Andrei seems unfit to design D tuples).
 Other corner cases I can think about: is one-element tuple 
 equivalent to that one element,

Nope, this is sloppy.
 is array literal a tuple,

Nope. But some explicit conversions are useful.
 is string literal a tuple,

The same as arrays.
 how to infer packed and unpacked tuples,

I don't understand.
 how to remember all these subtle features?

Really, a well designed tuple type is a very simple datatype. So a well designed tuple has a natural syntax and a very simple semantics with no corner cases, that is easy to remember. If it gets hard to remember, it should be redesigned or simplified. Bye, bearophile
Mar 28 2014
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 On 3/28/14, 2:15 AM, bearophile wrote:
 OK. (But from the last posts on the topic Andrei seems unfit 
 to design D
 tuples).

Where did that one come from? Oh boy.

It came mostly from this answer of yours:
 That would be a different function but same syntax. In fact
 for safety I favor myFunc().scatter(a, b, c)

A syntax like that misses the points of the discussions we have had why a better tuple syntax is useful. Bye, bearophile
Mar 28 2014