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?

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.

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

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

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

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

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.

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

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

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