Jump to page: 1 27  
Page
Thread overview
Killing the comma operator
May 10, 2016
Mathias Lang
May 10, 2016
Guillaume Piolat
May 10, 2016
Brian Schott
May 10, 2016
Seb
May 10, 2016
H. S. Teoh
May 11, 2016
Kagamin
May 11, 2016
ZombineDev
May 10, 2016
deadalnix
May 11, 2016
Lionello Lunesu
May 11, 2016
deadalnix
May 12, 2016
Lionello Lunesu
May 13, 2016
Nick Treleaven
May 21, 2016
Lionello Lunesu
May 10, 2016
Martin Krejcirik
May 10, 2016
ixid
May 10, 2016
Tomer Filiba
May 10, 2016
Meta
May 10, 2016
Timon Gehr
May 10, 2016
Meta
May 10, 2016
Timon Gehr
May 10, 2016
deadalnix
May 10, 2016
Timon Gehr
May 10, 2016
Observer
May 10, 2016
Timon Gehr
May 10, 2016
Timon Gehr
May 10, 2016
Timon Gehr
May 10, 2016
Stefan Koch
May 10, 2016
Nordlöw
May 10, 2016
mogu
May 11, 2016
Mithun Hunsur
May 11, 2016
Kagamin
May 11, 2016
ZombineDev
May 11, 2016
Timon Gehr
May 11, 2016
Jacob Carlborg
May 10, 2016
Andy Smith
May 10, 2016
deadalnix
May 10, 2016
H. S. Teoh
May 10, 2016
NotSpooky
May 11, 2016
Gopan
May 11, 2016
burjui
May 11, 2016
H. S. Teoh
May 11, 2016
deadalnix
May 11, 2016
H. S. Teoh
May 11, 2016
deadalnix
May 12, 2016
Mathias Lang
May 11, 2016
Nick Treleaven
May 11, 2016
H. S. Teoh
May 11, 2016
Gopan
May 11, 2016
Kagamin
May 11, 2016
Kagamin
May 11, 2016
Kagamin
May 11, 2016
Gopan
May 12, 2016
Kagamin
May 12, 2016
Claude
Jun 10, 2016
Mathias Lang
Jun 10, 2016
H. S. Teoh
May 10, 2016
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
May 10, 2016
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.

May 10, 2016
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.
May 10, 2016
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
May 10, 2016
I'd prefer just adding a warning where appropriate.

May 10, 2016
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
May 10, 2016
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.
May 10, 2016
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!
May 10, 2016
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
May 10, 2016
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
« First   ‹ Prev
1 2 3 4 5 6 7