March 27, 2014 Re: Changing the behavior of the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Wednesday, 26 March 2014 at 23:00:29 UTC, Andrei Alexandrescu
wrote:
> On 3/26/14, 3:13 PM, Timon Gehr wrote:
>> On 03/26/2014 08:49 PM, Andrei Alexandrescu wrote:
>>>>
>>>> I don't agree. It's much better to fix the little breaking changes now,
>>>> and think about non-breaking improvements later. Because later the
>>>> breaking changes will become less and less possible.
>>>
>>> That later is already now.
>>
>> So how come there exists this thread on breaking the comma operator?
>
> Because it's arguably worth it. -- Andrei
Because it has been agreed a long time a ago, but now we are
backpedaling because we can't break code as much as we used to.
That being said, I'm quite satisfied with Andrei's void return
value proposal.
|
March 27, 2014 Re: Changing the behavior of the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | On Wed, 26 Mar 2014 17:32:00 -0400, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote: > On 3/26/2014 7:44 AM, "Marc Schütz" <schuetzm@gmx.net>" wrote: >> This is valid in both C and C++: >> >> i, j = 0, 1; >> >> It is equivalent to the following: >> >> i; >> j = 0; >> 1; >> > > Under the proposal, the "0, 1" would be void, so it wouldn't compile in D. Therefore, the rule about moving C code to D safely is not violated. > This part of the subthread is about the future plans to possibly use comma operators to mean tuples. This C/C++ code will still be valid then, and when someone ports to D, might get a nasty silently compiling surprise. But, I think the proposal to re-introduce ',' as a tuple operator would not affect this code, it would remain a 3-element tuple, with i, j, 1 as elements (after setting j to 0 of course). '=' has precedence over ','. The second statement would be a problem (i, j) = (0, 1), but clearly, this would not be a valid use case. I can envision there may be some valid use cases of that form, however. -Steve |
March 27, 2014 Re: Changing the behavior of the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Wed, 26 Mar 2014 13:27:17 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote: > On 3/26/14, 7:39 AM, Steven Schveighoffer wrote: >> Frequently, I have situations where I do not put a comma on the last >> element. > > Big mistake :o). -- Andrei A trailing comma in a list looks so wrong to me :) It looks like an unfinished declaration. I just as frequently have trailing commas because I delete the last element and forget to remove the comma on the "new" last element :D -Steve |
March 27, 2014 Re: Changing the behavior of the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Thursday, 27 March 2014 at 02:08:50 UTC, Steven Schveighoffer wrote:
> On Wed, 26 Mar 2014 17:32:00 -0400, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
>
>> On 3/26/2014 7:44 AM, "Marc Schütz" <schuetzm@gmx.net>" wrote:
>>> This is valid in both C and C++:
>>>
>>> i, j = 0, 1;
>>>
>>> It is equivalent to the following:
>>>
>>> i;
>>> j = 0;
>>> 1;
>>>
>>
>> Under the proposal, the "0, 1" would be void, so it wouldn't compile in D. Therefore, the rule about moving C code to D safely is not violated.
>>
>
> This part of the subthread is about the future plans to possibly use comma operators to mean tuples. This C/C++ code will still be valid then, and when someone ports to D, might get a nasty silently compiling surprise.
>
> But, I think the proposal to re-introduce ',' as a tuple operator would not affect this code, it would remain a 3-element tuple, with i, j, 1 as elements (after setting j to 0 of course). '=' has precedence over ','.
>
> The second statement would be a problem (i, j) = (0, 1), but clearly, this would not be a valid use case. I can envision there may be some valid use cases of that form, however.
>
> -Steve
I think you get operator priority wrong and it will be (i), (j = 0), (1). I added extra () to show how operator priority works.
|
March 27, 2014 Re: Changing the behavior of the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Wed, 26 Mar 2014 22:02:44 -0000, Timon Gehr <timon.gehr@gmx.ch> wrote: > On 03/26/2014 05:19 PM, H. S. Teoh wrote: >> int x = 1, 5; // hands up, how many understand what this does? > > Nothing. This fails to parse because at that place ',' is expected to be a separator for declarators. Spectacularly proving his point :p R -- Using Opera's revolutionary email client: http://www.opera.com/mail/ |
March 27, 2014 Re: Changing the behavior of the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On Wednesday, 26 March 2014 at 16:21:01 UTC, H. S. Teoh wrote:
> What we're proposing is to get rid of things like this:
>
> int x = 1, 5; // hands up, how many understand what this does?
This proposal gets rid of this while keeping the comma operator.
|
March 27, 2014 Re: Changing the behavior of the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On Thursday, 27 March 2014 at 11:32:45 UTC, Kagamin wrote:
> On Wednesday, 26 March 2014 at 16:21:01 UTC, H. S. Teoh wrote:
>> What we're proposing is to get rid of things like this:
>>
>> int x = 1, 5; // hands up, how many understand what this does?
>
> This proposal gets rid of this while keeping the comma operator.
+1 to dropping to comma operator.
This is what I would like to see illegal, forcing a refactor of code:
if (((vertex= null), same.vertices)) for (blah){}
Every time it catches me out and I misread the code to be:
if(vertex == null && same.vertices) for (blah) {}
Cheers,
ed
|
March 27, 2014 Re: Changing the behavior of the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | On Thursday, 27 March 2014 at 10:39:58 UTC, Regan Heath wrote:
> On Wed, 26 Mar 2014 22:02:44 -0000, Timon Gehr <timon.gehr@gmx.ch> wrote:
>
>> On 03/26/2014 05:19 PM, H. S. Teoh wrote:
>>> int x = 1, 5; // hands up, how many understand what this does?
>>
>> Nothing. This fails to parse because at that place ',' is expected to be a separator for declarators.
>
> Spectacularly proving his point :p
Did he want to kill the declaration statement too?
|
March 27, 2014 Re: Changing the behavior of the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to ed | On Thursday, 27 March 2014 at 11:43:36 UTC, ed wrote:
> On Thursday, 27 March 2014 at 11:32:45 UTC, Kagamin wrote:
>> On Wednesday, 26 March 2014 at 16:21:01 UTC, H. S. Teoh wrote:
>>> What we're proposing is to get rid of things like this:
>>>
>>> int x = 1, 5; // hands up, how many understand what this does?
>>
>> This proposal gets rid of this while keeping the comma operator.
>
> +1 to dropping to comma operator.
>
> This is what I would like to see illegal, forcing a refactor of code:
>
> if (((vertex= null), same.vertices)) for (blah){}
>
>
> Every time it catches me out and I misread the code to be:
>
> if(vertex == null && same.vertices) for (blah) {}
>
>
> Cheers,
> ed
s/== null/is null/
|
March 27, 2014 Re: Changing the behavior of the comma operator | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On Thursday, 27 March 2014 at 11:32:45 UTC, Kagamin wrote:
> On Wednesday, 26 March 2014 at 16:21:01 UTC, H. S. Teoh wrote:
>> What we're proposing is to get rid of things like this:
>>
>> int x = 1, 5; // hands up, how many understand what this does?
>
> This proposal gets rid of this while keeping the comma operator.
The point is that this is not the comma operator, and is already illegal to begin with.
*This* is what is being made illegal
int x = (1, 5);
The point being that most programmers don't actually understand all the subtleties of comma operator vs argument listing. Mysielf included (I also thought that was a comma operator...)
Also, not to mention issues with things like operator precedence...
a = 1, 5 + 2; //What's a?
a = (1 + 2, 5); //What's a?
Speaking of which:
a = 1, 5 + 2;
Why doesn't dmd emit an "operator , has no effect" error?
Or
a = (1 + 2, 5)
Why doesn't dmd emit an "operator + has no effect" error?
|
Copyright © 1999-2021 by the D Language Foundation