After the recent discussions regarding the comma operator, and after inspecting the patterns of code affected by it, Walter and I would back up the following change to the D language:

1. The comma operator stays with its current syntax.

2. The semantics is the same unless warnings are enabled with "-w"

3. In "-w" mode, semantics are changed in that the type of the comma operator is NOT the type of its last expression, but instead it's void.

4. Later on the warning will be promoted to a deprecation followed by removal from the language.

5. Reintroducing the result type as a tuple remains a future possibility.

We believe the change would be beneficial for the following reasons:

1. Based on druntime and phobos, the breakage is likely to be infrequent.

2. The change may catch (and has caught) important bugs caused by misplacing closing parentheses.

3. Most code using the result of the comma expression looks foreign even to seasoned programmers and might gain in clarity from a refactor.


Please reply to discuss this possibility.


Andrei

On Tuesday, 25 March 2014 at 17:33:20 UTC, Andrei Alexandrescu wrote:
> 2. The change may catch (and has caught) important bugs caused by misplacing closing parentheses.
>
> Andrei

I think it's worth it, if only for this.

On Tuesday, 25 March 2014 at 17:33:20 UTC, Andrei Alexandrescu wrote:
> After the recent discussions regarding the comma operator, and after inspecting the patterns of code affected by it, Walter and I would back up the following change to the D language:
>
> 1. The comma operator stays with its current syntax.
>
> 2. The semantics is the same unless warnings are enabled with "-w"
>
> 3. In "-w" mode, semantics are changed in that the type of the comma operator is NOT the type of its last expression, but instead it's void.
>
> 4. Later on the warning will be promoted to a deprecation followed by removal from the language.
>
> 5. Reintroducing the result type as a tuple remains a future possibility.
>
> We believe the change would be beneficial for the following reasons:
>
> 1. Based on druntime and phobos, the breakage is likely to be infrequent.
>
> 2. The change may catch (and has caught) important bugs caused by misplacing closing parentheses.
>
> 3. Most code using the result of the comma expression looks foreign even to seasoned programmers and might gain in clarity from a refactor.
>
>
> Please reply to discuss this possibility.
>
>
> Andrei

At first I throught didn't remove comma operator from language because it will make(possibly) hard to C/C++ guys porting code to D but instead of it will be allowed but return void type? why is this better than remove?
but I'm happy this int a = 123,456; will give a type error instead of compile.

On Tuesday, 25 March 2014 at 17:33:20 UTC, Andrei Alexandrescu wrote:
> After the recent discussions regarding the comma operator, and after inspecting the patterns of code affected by it, Walter and I would back up the following change to the D language:
>
> 1. The comma operator stays with its current syntax.
>
> 2. The semantics is the same unless warnings are enabled with "-w"
>
> 3. In "-w" mode, semantics are changed in that the type of the comma operator is NOT the type of its last expression, but instead it's void.
>
> 4. Later on the warning will be promoted to a deprecation followed by removal from the language.
>
> 5. Reintroducing the result type as a tuple remains a future possibility.
>
> We believe the change would be beneficial for the following reasons:
>
> 1. Based on druntime and phobos, the breakage is likely to be infrequent.
>
> 2. The change may catch (and has caught) important bugs caused by misplacing closing parentheses.
>
> 3. Most code using the result of the comma expression looks foreign even to seasoned programmers and might gain in clarity from a refactor.
>
>
> Please reply to discuss this possibility.
>
>
> Andrei

You are missing necessary step between (3) and (4) : making any usage of comma operator a warning. According to current language feature deprecation practices one cannot just go to a deprecation message omitting _exact same_ warning (judging by my observations, of course).

This was why I have objected against this compromise initially - it only makes transition process more complicated if you are going to remove comma anyway and reduction in breakage feels questionable (unless I have missed some hard data).

Still, full support for anything that removes comma expression completely in the end.

2014-03-26 2:33 GMT+09:00 Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org
>:

> After the recent discussions regarding the comma operator, and after inspecting the patterns of code affected by it, Walter and I would back up the following change to the D language:
>
> 1. The comma operator stays with its current syntax.
>
> 2. The semantics is the same unless warnings are enabled with "-w"
>
> 3. In "-w" mode, semantics are changed in that the type of the comma operator is NOT the type of its last expression, but instead it's void.
>
> 4. Later on the warning will be promoted to a deprecation followed by removal from the language.
>
> 5. Reintroducing the result type as a tuple remains a future possibility.
>
> We believe the change would be beneficial for the following reasons:
>
> 1. Based on druntime and phobos, the breakage is likely to be infrequent.
>
> 2. The change may catch (and has caught) important bugs caused by
> misplacing closing parentheses.
>
> 3. Most code using the result of the comma expression looks foreign even to seasoned programmers and might gain in clarity from a refactor.
>
>
> Please reply to discuss this possibility.


Sounds good. Typing comma expressions as void would be a good way.

Kenji Hara

Andrei Alexandrescu:

> Please reply to discuss this possibility.

I think total removal of the comma operator could offer more readable D code.

A counting of the answers from the precedent thread:

Total removal: Asman01, deadalnix, Dicebot, John Colvin, Mike James, bearophile, Philpax, ponce, Simen Kjærås, Meta, Daniel Murphy, H. S. Teoh, Sean Kelly, ilya-stromberg.

Neutral or slightly against removal: Adam D. Ruppe, Nick Treleaven.

Partially against removal: Kenji Hara.

OK with just removal of return: Andrei Alexandrescu, Meta, Daniel Murphy, deadalnix, John Colvin, perhaps Steven Schveighoffer.

Do not like just the removal of return: Adam D. Ruppe, Brian Schott, Dicebot.

I don't know the answers of: Andrej Mitrovic, Sarath Kodali, Don.

Bye,
bearophile

On Tue, 25 Mar 2014 13:33:21 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> After the recent discussions regarding the comma operator, and after inspecting the patterns of code affected by it, Walter and I would back up the following change to the D language:
>
> 1. The comma operator stays with its current syntax.
>
> 2. The semantics is the same unless warnings are enabled with "-w"
>
> 3. In "-w" mode, semantics are changed in that the type of the comma operator is NOT the type of its last expression, but instead it's void.
>
> 4. Later on the warning will be promoted to a deprecation followed by removal from the language.
>
> 5. Reintroducing the result type as a tuple remains a future possibility.

I think this should not be done. Note that even though code which is D could reintroduce commas safely, C code will still exist at that time, and likely need porting to D. The principle that C code should either do the same thing, or not compile, would be violated.

> 1. Based on druntime and phobos, the breakage is likely to be infrequent.
>
> 2. The change may catch (and has caught) important bugs caused by misplacing closing parentheses.
>
> 3. Most code using the result of the comma expression looks foreign even to seasoned programmers and might gain in clarity from a refactor.

I agree with the change, up through step 4. I think the result of comma expression should *ALWAYS* be void.

-Steve

On 3/25/14, 10:45 AM, Asman01 wrote:
> On Tuesday, 25 March 2014 at 17:33:20 UTC, Andrei Alexandrescu wrote:
>> After the recent discussions regarding the comma operator, and after
>> inspecting the patterns of code affected by it, Walter and I would
>> back up the following change to the D language:
>>
>> 1. The comma operator stays with its current syntax.
>>
>> 2. The semantics is the same unless warnings are enabled with "-w"
>>
>> 3. In "-w" mode, semantics are changed in that the type of the comma
>> operator is NOT the type of its last expression, but instead it's void.
>>
>> 4. Later on the warning will be promoted to a deprecation followed by
>> removal from the language.
>>
>> 5. Reintroducing the result type as a tuple remains a future possibility.
>>
>> We believe the change would be beneficial for the following reasons:
>>
>> 1. Based on druntime and phobos, the breakage is likely to be infrequent.
>>
>> 2. The change may catch (and has caught) important bugs caused by
>> misplacing closing parentheses.
>>
>> 3. Most code using the result of the comma expression looks foreign
>> even to seasoned programmers and might gain in clarity from a refactor.
>>
>>
>> Please reply to discuss this possibility.
>>
>>
>> Andrei
>
> At first I throught didn't remove comma operator from language because
> it will make(possibly) hard to C/C++ guys porting code to D but instead
> of it will be allowed but return void type? why is this better than remove?

You are responding to the post replying all of these questions.

Adnrei

> Partially against removal: Kenji Hara.

There is also etcimon against the removal of the comma. And Kenji Hara is OK with just removing the return.

Bye,
bearophile

On 3/25/14, 10:58 AM, bearophile wrote:
> Andrei Alexandrescu:
>
>> Please reply to discuss this possibility.
>
> I think total removal of the comma operator could offer more readable D
> code.
>
> A counting of the answers from the precedent thread:

This is not a vote! Please discuss arguments, not headcount. Thanks! -- Andrei