Thread overview | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
May 10, 2016 Killing the comma operator | ||||
---|---|---|---|---|
| ||||
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 Re: Killing the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mathias Lang | 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 Re: Killing the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Guillaume Piolat | 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 Re: Killing the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mathias Lang | 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 Re: Killing the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mathias Lang | I'd prefer just adding a warning where appropriate. |
May 10, 2016 Re: Killing the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 Re: Killing the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mathias Lang | 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 Re: Killing the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to ixid | 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 Re: Killing the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 Re: Killing the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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
|
Copyright © 1999-2021 by the D Language Foundation