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:
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
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 "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 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 parent reply "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
next sibling parent reply "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
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 reply 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
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 reply "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
parent reply "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
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 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
next sibling parent reply "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
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 "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
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
next sibling parent reply "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
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 reply 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
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 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 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 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 parent reply "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
next sibling parent reply 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
parent reply "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
parent reply "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
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 parent reply "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
next sibling parent reply "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
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 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 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 reply "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
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 parent reply "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
parent reply 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
parent reply "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=


n  =


 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



  parent reply "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



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



 next sibling parent reply "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



  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  parent reply "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



  parent reply "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



  parent reply "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



  parent reply 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



  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



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 reply 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



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



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



  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



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



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