Am 23.03.2014 22:08, schrieb Asman01:
> On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote:
>> Discuss: https://github.com/D-Programming-Language/dmd/pull/3399
>>
>> Andrei
>
> Then things like this c = f(),b*c; became invalid? if so, yes. I did a
> lot of C and never found this useful just unlike.

Interesting interview questions. :)

On 2014-03-23 20:56, Andrei Alexandrescu wrote:
> Discuss: https://github.com/D-Programming-Language/dmd/pull/3399
>
> Andrei

I'd shed no tears if the comma operator were gone.

--
  Simen

On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote:
> Discuss: https://github.com/D-Programming-Language/dmd/pull/3399
>
> Andrei

You mentioned on the Github PR that this broke some Phobos (and Druntime?) code. What was the extent of the breakage? If it's small, I'd say give it a year-long deprecation period and then be done with it forever.

On 3/23/14, 5:41 PM, Meta wrote:
> On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote:
>> Discuss: https://github.com/D-Programming-Language/dmd/pull/3399
>>
>> Andrei
>
> You mentioned on the Github PR that this broke some Phobos (and
> Druntime?) code. What was the extent of the breakage? If it's small, I'd
> say give it a year-long deprecation period and then be done with it
> forever.

The extent of the breakage is NOT among the top factors. Once a piece of code goes from "compiles" to "doesn't compile" that lowers the acceptance level by an order of magnitude. Only after that, the extent of the breakage has any import.

Top factors:

0. Any silent breakages or changes in semantics? 100000000x

1. How frequent is the breakage? Is most code going to still work? 100x

2. How much does fixing the breakage improve code? Was the breaking code incorrect for the most part? 100x


Andrei

Andrei Alexandrescu:

> Discuss: https://github.com/D-Programming-Language/dmd/pull/3399

Are you going to listen to people in this thread or are just going to say that people in the newsgroup are not representative of the whole community of D users?

Regarding the "progress", I'd like a good built-in syntax to unpack tuples in assignments, inside function signatures, in foreach statements, and more, because the syntactic contortions I currently adopt to use tuples in D are bad.

Bye,
bearophile

On 3/23/14, 6:09 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> Discuss: https://github.com/D-Programming-Language/dmd/pull/3399
>
> Are you going to listen to people in this thread or are just going to
> say that people in the newsgroup are not representative of the whole
> community of D users?

Argumentum ad populum has low pull on me. Come with good arguments, not "half a dozen people can't be wrong".

> Regarding the "progress", I'd like a good built-in syntax to unpack
> tuples in assignments, inside function signatures, in foreach
> statements, and more, because the syntactic contortions I currently
> adopt to use tuples in D are bad.

Some examples of what you're trying to achieve would be great, with the understanding that you're looking at at least five years until we'd be able to change anything about the use of comma.


Andrei

Andrei Alexandrescu:

> The extent of the breakage is NOT among the top factors. Once a piece of code goes from "compiles" to "doesn't compile" that lowers the acceptance level by an order of magnitude. Only after that, the extent of the breakage has any import.

Are you going to ignore the voices in this thread? If that's true, what's the point of asking to the newsgroup? Perhaps just to collect few people that agree with you, to show you are listening?

Bye,
bearophile

On 3/23/14, 6:18 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> The extent of the breakage is NOT among the top factors. Once a piece
>> of code goes from "compiles" to "doesn't compile" that lowers the
>> acceptance level by an order of magnitude. Only after that, the extent
>> of the breakage has any import.
>
> Are you going to ignore the voices in this thread?

I'm not going to ignore good argument made by the voices in this thread. -- Andrei

On 3/23/14, 6:18 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> The extent of the breakage is NOT among the top factors. Once a piece
>> of code goes from "compiles" to "doesn't compile" that lowers the
>> acceptance level by an order of magnitude. Only after that, the extent
>> of the breakage has any import.
>
> Are you going to ignore the voices in this thread? If that's true,
> what's the point of asking to the newsgroup? Perhaps just to collect few
> people that agree with you, to show you are listening?

And by the way the irony here is that you seem to ignore my argument.

Andrei

2014-03-24 10:09 GMT+09:00 bearophile <bearophileHUGS@lycos.com>:

> Andrei Alexandrescu:
>
>  Discuss: https://github.com/D-Programming-Language/dmd/pull/3399
>>
>
> Regarding the "progress", I'd like a good built-in syntax to unpack tuples in assignments, inside function signatures, in foreach statements, and more, because the syntactic contortions I currently adopt to use tuples in D are bad.
>

I'm partially against to it.

1. I think removing comma operator does not have useful effect for tuple syntax discussion. For example:

   1a. If you want to use parenthesis syntax (...) for tuple, we should
resolve one-element tuple ambiguity first.
         (exp)   // one-element tuple, or just an expression ?
      And,  removing comma operator does not resolve this issue.

   1b. If you choose other syntax for tuple, comma operator will be no
longer related to tuple syntax discussion.
        {exp, exp2}  // eg. using brace for tuple syntax no longer touch to
comma operator

2. Indeed in some case comma operator is bug-prone, but if it is used directly on the ExpStatement, it's still useful to me.

    foreach (e; exp1, exp2) {}   // maybe bug?
    if (cond) exp1, exp2;   // in most case, this is not a bug.

   So, completely removing comma operator will cause negative affect in
some cases.

Kenji Hara