Changing the behavior of the comma operator

[H. S. Teoh]

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.