May 10, 2016 Re: Killing the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brian Schott | On Tuesday, 10 May 2016 at 10:02:53 UTC, Brian Schott wrote:
> 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.
... and then send the ashes to space!
Free the tuples!
|
May 10, 2016 Re: Killing the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mathias Lang | > 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.
|
May 10, 2016 Re: Killing the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Meta | On 10.05.2016 15:53, 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.
That's not really forward compatible to tuple support, e.g., one can query typeof((1,2)).
|
May 10, 2016 Re: Killing the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Tuesday, 10 May 2016 at 10:09:40 UTC, 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
Let's just make it of void type, there was plan to recycle the syntax maybe, but whatever we do in the future, this is the sensible first step.
|
May 10, 2016 Re: Killing the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Tuesday, 10 May 2016 at 14:07:35 UTC, Timon Gehr wrote:
> That's not really forward compatible to tuple support, e.g., one can query typeof((1,2)).
I am becoming increasingly dubious that D will ever have built-in tuples.
|
May 10, 2016 Re: Killing the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Meta | 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
|
May 10, 2016 Re: Killing the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On 10.05.2016 19:57, 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
I suggest we make it a statement instead of an expression and add special syntax for for-loops.
|
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: > So, following DConf2016, I raised a P.R. to deprecate usage of the comma expressions, except within `for` loops increment [5]. > ... > 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 ? 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. While I haven't been part of any D-language discussions about this operator, I fail to see it as causing serious code problems. Perl in particular uses commas extensively, both as a C-type operator and in list construction. Perl is helped in that regard by distinguishing scalar context (C-type operator) from list context (list argument separator). The fact of the matter is, anyone who learns Perl finds this spectacularly unconfusing. So perhaps a better solution than throwing away the operator in D is to think about supporting proper context-awareness. It's been done before (as demonstrated in Perl) with great success, so we definitely can't say it's an impossibility. And D already understands one ubiquitous list-construction context, namely the act of passing arguments to functions. 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, 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'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, to avoid use of the comma operator. That's because the code earlier in the loop body might contain a "continue" statement, and that would skip right by the assignment if it were part of the loop body instead of being part of the loop-condition expression. So whatever is done with the comma operator in D, you first need to enumerate all the places where it is truly useful, and make sure you support those cases well. I find the present syntax very simple and very readable, and so would be very reluctant to give it up. If there is really a need to do so, then allowing brace-enclosed statement expressions seems to me to be a reasonable compromise, requiring only clean, very little extra syntax. If you do make this kind of transition, it needs to be spread across multiple compiler releases. In particular, you should never proceed to the next stage until *all* the major compilers (DMD, GCC, LDC) have caught up to the present stage. * Release 1: Implement statement expressions, allow them in all the right contexts, and document them. Using this release, acquire real-world experience and fix any implementation bugs. * Release 2: Now that statement expressions are known to be well-supported, document them as being idiomatic in common contexts such as loop control, recommend their use, and document that the comma operator will be deprecated in future releases. Provide a compiler option (documented but defaulted off at this stage) to warn about use of the comma operator in places where a statement expression would do the trick instead, to allow developers to quickly locate places that deserve some attention. Make no other changes to the compilers at this stage, because it is only now that statement expressions will be known to be safe enough for general use, and you want to allow a period for pleasant, well-planned conversions before the hammer comes down. Also in this timeframe, see if dfix can be equipped to handle such conversions automatically. * Release 3: Still allow the comma operator, but now default the comma-operator deprecation warning to be on. And declare in the documentation that this is the case, and that this will be the last release in which the comma operator is still allowed. * Release 4: Obsolete the comma operator entirely. Have the compiler generate an error, aborting the compilation, instead of a warning, if comma operators are found during compilation. * Release 5: Finally allow the language definition to re-use the comma for other purposes (tuple construction, or whatever). A slow evolution like that is the only sane way to proceed. But again, that's only if context-awareness is not possible, and I find that hard to believe. |
May 10, 2016 Re: Killing the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mathias Lang | On 10.05.2016 11:52, 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: > > Do you like comma expressions, It's sometimes a useful thing to do. But every usage of the comma operator, e.g. (e1,e2,e3), could just be e.g. (e1,e2,e3)[$-1] instead with tuple syntax, and the latter is a lot more explicit. The two usages that don't conflict with tuple syntax (i.e. as a statement/inside a for-loop) could just be left in. They tend not to hurt. > and think its presence in the language is > more pro than con ? No. Kill it. |
May 10, 2016 Re: Killing the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Tuesday, 10 May 2016 at 21:30:35 UTC, Timon Gehr wrote:
> Kill it.
I agree.
There is always another way.
|
Copyright © 1999-2021 by the D Language Foundation