Killing the comma operator (page 3)

On Tuesday, 10 May 2016 at 17:57:38 UTC, Steven Schveighoffer wrote: > On 5/10/16 9:53 AM, Meta wrote: >>> Do you like comma expressions, and think its presence in the language >>> is more pro than con ? >> >> It should've been killed off a long time ago. It only causes bugs and >> can easily be replaced with a library feature if necessary. I think >> Andrei suggested that it should be changed so that the comma expression >> returns `void` instead of the last expression evaluated. > > Andrei pointed out (in an earlier PR) that making the return type void isn't correct either. You can still use void in some cases, e.g.: > > auto foo(a) > { > return ++a, ++a; > } > > This should still be disallowed. > > -Steve It doesn't make it incorrect, just insufficient.

May 10, 2016

Re: Killing the comma operator

Posted by Timon Gehr
in reply to Observer

Permalink

Timon Gehr

Posted in reply to Observer

Permalink

On 10.05.2016 23:30, Observer wrote:
> I've programmed in C for decades, and in Perl for a decade, and *never*
> had a problem with the comma operator in either language.

Neither have I. It's a cheap claim to make though, and it does not really add anything relevant to the discussion.

> While I
> haven't been part of any D-language discussions about this operator,
> I fail to see it as causing serious code problems.
> ...

Lack of proper tuples is a serious enough problem.

>
> Now admittedly, there aren't too many situations where the comma acting
> as a C-type operator finds a use.  But commas in all of the for-loop
> control expressions, not just the increment clause, are definitely useful.
> And more than that, they're useful whenever you want to execute several
> independent calculations in some context that doesn't allow "statement
> expressions".  See http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
> for how this is supported in GNU C, with a very clean syntax.  I would
> strongly suggest that if you want to deprecate the comma operator for
> some reason, that you build statement expressions into the language,

The comma operator does not allow executing statements, but delegates can do this even today.

auto var = { stmt1; stmt2; stmt3; return expr; }();

Also, tuples can do everything that comma expressions can.


> allow them in all contexts where comma operators are presently very
> common, and document this widely as a standard idiom in the language.
>
> Note that for-loops are definitely not the only places where comma
> operators come in handy.  As an example, I wrote a very long critique
> of TDPL, and sent it off to Andrei late last year.  In an item for
> page 382, I provided a lot of replacement text to clarify the example.
> Within that text was the following delegate code, showing excellent use
> of the comma operator in a do-while loop-control context:
>
> (i) {
>      bool __done = false;
>      do {
>          writeln(i);
>      } while (__done = true, !__done);
>      // __done is still false if and only if the loop body executed
>      // a break and skipped the reassignment within the while test.
>      return __done ? 0 : 1;
> }

That loop body does not contain any breaks. It would be nice if the presented use case actually made sense. Also, just write

while(_done=true,false);

> That's actually rather tricky code.  In the general case for such a loop,
> you cannot simply move the "__done = true" assignment and place it at the
> end of the loop body,

Which a careless maintainer of the code might still do, and now you have a bug. Whatever your actual use case was, I think it is likely that there is a more elegant solution that does not require a comment (about control flow!) to prevent such accidents from happening.

On 10.05.2016 23:47, deadalnix wrote: > On Tuesday, 10 May 2016 at 17:57:38 UTC, Steven Schveighoffer wrote: >> On 5/10/16 9:53 AM, Meta wrote: >>>> Do you like comma expressions, and think its presence in the language >>>> is more pro than con ? >>> >>> It should've been killed off a long time ago. It only causes bugs and >>> can easily be replaced with a library feature if necessary. I think >>> Andrei suggested that it should be changed so that the comma expression >>> returns `void` instead of the last expression evaluated. >> >> Andrei pointed out (in an earlier PR) that making the return type void >> isn't correct either. You can still use void in some cases, e.g.: >> >> auto foo(a) >> { >> return ++a, ++a; >> } >> >> This should still be disallowed. >> >> -Steve > > It doesn't make it incorrect, just insufficient. > Let's make it correct and sufficient.

On Tue, May 10, 2016 at 09:46:36PM +0000, deadalnix via Digitalmars-d wrote: > On Tuesday, 10 May 2016 at 21:30:35 UTC, Timon Gehr wrote: > >>and think its presence in the language is more pro than con ? > > > >No. Kill it. > > With FIRE ! And extreme prejudice. T -- That's not a bug; that's a feature!

On Tuesday, 10 May 2016 at 21:33:47 UTC, Stefan Koch wrote: > On Tuesday, 10 May 2016 at 21:30:35 UTC, Timon Gehr wrote: >> Kill it. > > I agree. > There is always another way. +1 for killing. If there's a language feature that allows someone of Ali's calibre to write some code expecting one behaviour whilst under the hood receiving a completely different behaviour then I think that's a clear case for removing and/or ring-fencing said feature, since it clearly violates the principle of least surprise. If it can trip up Ali then we mere mortals are clearly doomed!!!! :-) Cheers, A.

On 10.05.2016 23:52, Timon Gehr wrote: > > Also, tuples can do everything that comma expressions can. Actually, that doesn't work for 'void' (because 'void' is a type that is not actually a type) in every conceivable design. Should probably just be made to work.

On Tuesday, 10 May 2016 at 21:49:10 UTC, Nordlöw wrote: > On Tuesday, 10 May 2016 at 21:33:47 UTC, Stefan Koch wrote: >> On Tuesday, 10 May 2016 at 21:30:35 UTC, Timon Gehr wrote: >>> Kill it. >> >> I agree. > > Agreed. Builtin tuple syntax is far more useful. +1. And personally, match is expected then.

Forums