If you were attending DConf2016, or watched Ali (excellent) talk [1] at some point, you probably remember this piece of code:

`synchronized (lockA, lockB)`

As documented in TDPL (thanks @schveiguy) [2].
Unfortunately, as someone pointed out, this isn't implemented, but still compile "thanks" to the comma operator [3].

There are many reasons to hate this almost invisible false friend.
One more example is returning a string containing a comma to mix it in. If you're not familiar enough with the language, you'll end up wondering why it isn't behaving as expected [4].
But there can be situations where it's useful. For example the following code isn't rare:

`for (; !a.empty && !b.empty; a.popFront, b.popFront) { /* Do stuff with ranges */ }`

Rewriting this wouldn't look as nice.

So, following DConf2016, I raised a P.R. to deprecate usage of the comma expressions, except within `for` loops increment [5].
The feedback we already got from druntime / phobos was pretty good: out of three occurrences in druntime, one was a bug [7]. Not a single message was triggered in Phobos, since it's using Dscanner, which is warning against it in assignments and (nowadays) synchronized [6].

It seems there is a reasonable ground to kill it. However, there have been legitimated concern about code breakage, so we would like to hear from other people:

Do you like comma expressions, and think its presence in the language is more pro than con ?


[1]: http://www.ustream.tv/recorded/86352137/highlight/699197
[2]: http://www.informit.com/articles/article.aspx?p=1609144&seqNum=15
[3]: https://github.com/dlang/dmd/blob/81cb1c8a6a4d594bd17bfc8e263b72ed72ff8cf3/src/parse.d#L5662-L5683
[4]: https://issues.dlang.org/show_bug.cgi?id=15993
[5]: https://github.com/dlang/dmd/pull/5737
[6]: https://github.com/Hackerpilot/Dscanner/blob/02f8f3c423a413d0f90e9d4698a2db9049e35b44/src/analysis/comma_expression.d
[7]: https://github.com/dlang/druntime/pull/1562

On Tuesday, 10 May 2016 at 09:52:07 UTC, Mathias Lang wrote:
>
> It seems there is a reasonable ground to kill it. However, there have been legitimated concern about code breakage, so we would like to hear from other people:
>

With all due restraint and care for breakage, I'd say to take the appropriate response:

KILL IT NOW, WITH FIRE

This isn't even an annoying code breakage, it's one that has an obvious, backward-compatible workaround that takes very little time. No such useless feature can justify the bugs.

On Tuesday, 10 May 2016 at 10:00:04 UTC, Guillaume Piolat wrote:
> KILL IT NOW, WITH FIRE

Then salt the ground it grew on and irradiate it.

The comma operator has stolen our ability to have tuples and in return it has given us bugs.

On 5/10/16 12:52 PM, Mathias Lang wrote:
> So, following DConf2016, I raised a P.R. to deprecate usage of the comma
> expressions, except within `for` loops increment [5].

The agreed-upon ideea was to allow uses that don't use the result (including for loops). No? -- Andrei

I'd prefer just adding a warning where appropriate.

On 5/10/16 1:09 PM, Andrei Alexandrescu wrote:
> On 5/10/16 12:52 PM, Mathias Lang wrote:
>> So, following DConf2016, I raised a P.R. to deprecate usage of the comma
>> expressions, except within `for` loops increment [5].
>
> The agreed-upon ideea was to allow uses that don't use the result
> (including for loops). No? -- Andrei

In fact I thought that got implemented a while ago, that's why I didn't insist much lately. -- Andrei

On Tuesday, 10 May 2016 at 09:52:07 UTC, Mathias Lang wrote:
> Do you like comma expressions, and think its presence in the language is more pro than con ?

Kill it with fire and hopefully we can have pretty tuple syntax like Swift and Go's.

On Tuesday, 10 May 2016 at 12:27:42 UTC, ixid wrote:
> Kill it with fire and hopefully we can have pretty tuple syntax like Swift and Go's.

Yes please!

On 5/10/16 6:13 AM, Andrei Alexandrescu wrote:
> On 5/10/16 1:09 PM, Andrei Alexandrescu wrote:
>> On 5/10/16 12:52 PM, Mathias Lang wrote:
>>> So, following DConf2016, I raised a P.R. to deprecate usage of the comma
>>> expressions, except within `for` loops increment [5].
>>
>> The agreed-upon ideea was to allow uses that don't use the result
>> (including for loops). No? -- Andrei
>
> In fact I thought that got implemented a while ago, that's why I didn't
> insist much lately. -- Andrei

It was never pulled. In fact, Marc Schütz just closed his PR when he found Mathias' PR. https://github.com/dlang/dmd/pull/5737#issuecomment-217946868

Note, there was some pretty good examples of (ab)use of the comma operator in one of those: https://github.com/dlang/dmd/pull/3399#issuecomment-38401339

For my input, I say kill it with fire, but only after deprecation :) When you see the kinds of bugs this has caused, it's horrifying.

I agree with your proposed solution (and so does Daniel Murphy BTW).

Sadly, I don't know if true tuple support can be had anytime soon, we may need to wait a long time for that.

BTW, has anyone proposed a replacement like this?

auto ref comma(T...)(auto ref T t) if(T.length > 1)
{
   return t[$-1];
}

Sure seems doable without a language feature. Just replace x, y with comma(x, y).

On 5/10/16 5:52 AM, Mathias Lang wrote:
> As documented in TDPL (thanks @schveiguy) [2].

I can't take credit for this, Ali pointed it out to me after his talk when I pointed out the problem during the talk. He said something along the lines of "I knew I had not made this up and had seen it somewhere!"

-Steve

On Tue, May 10, 2016 at 08:49:28AM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...]
> For my input, I say kill it with fire, but only after deprecation :) When you see the kinds of bugs this has caused, it's horrifying.

+1.  Kill the comma operator with fire.  Usage in for-loops should be done as special-case syntax, *not* as comma operator (i.e., "," in for loops should be accepted as part of for-loop statement syntax, not as part of expression syntax).

What to do with tuple syntax is a different kettle o' fish. But before we get there, we need to kill comma first. So let's at least take this first step.


--T