comma operator causes hard to spot bugs

H. S. Teoh hsteoh at quickfur.ath.cx
Sat Apr 21 11:08:51 PDT 2012


On Sat, Apr 21, 2012 at 05:06:13PM +0200, deadalnix wrote:
> Le 21/04/2012 14:51, Jonathan M Davis a écrit :
> >On Saturday, April 21, 2012 14:25:14 Alex Rønne Petersen wrote:
> >>No. It's an abomination, and it blocks more novel/interesting language
> >>design opportunities.
> >
> >There have been discussions about the comma operator before. I don't expect
> >that it's going anywhere, even though there are plenty of people who would
> >love to see it gone.
> >
> >- Jonathan M Davis
> 
> Add me on the list.

Me too.

While I admit I *do* like the idea of being able to overload the comma
operator to achieve things like what Blitz++ does in C++, I have a hard
time convincing myself that it's worth the troubles introduced by having
such an operator. (Besides, D's superior array literal syntax makes
Blitz++'s use of the comma operator unnecessary anyway.)

A common use case for the comma operator that people like to trot out is
in for-loops:

	for (i=1, j=2; i<10 && j<10; i++, j++) { ... }

But in my mind, this should be a syntactic feature of for-loops, not a
language-wide comma operator. I mean, it's not even consistent with
function call syntax (does f(a,b,c) mean a;b;f(c) because (a,b,c)
evaluates to c via the comma operator? -- and allowing things like
f((a,b,c)) to mean a;b;f(c) is useful only for writing obfuscated code;
I see no sane reason such monstrosities should be allowed in such a
clean language as D).

I contend that D's philosophy of doing the "right thing" by default
argues against having a comma operator.


T

-- 
A computer doesn't mind if its programs are put to purposes that don't match their names. -- D. Knuth


More information about the Digitalmars-d mailing list