On Monday, 24 March 2014 at 03:09:46 UTC, Andrei Alexandrescu wrote:
> That was in Phobos too. Fix:

Same misunderstanding all over again. Please understand that breaking code is the worst thing.

(yes, I'm quoting you back from a future message, but my point is that the compromise breaks code just like the full-blown deprecation, while leaving very little value behind.)

> There are of course other ways, too, including defining a function that returns its last argument.

Actually, that won't work. Since assert(0) returns void, it is not a valid function parameter.

But it could also be rewritten as a switch statement. So if the code is broken, one way or another we'd have to change that pattern but it is doable, so not the end of the world.

Andrei Alexandrescu:

> Yes, can't find it now. It was something like:
>
> foreach (e; chain(iota('a', 'я')), iota('A', 'Я')) {
>    ...
> }

Then if all or most comma-related bugs are caught with a more limited language change, then it's an interesting thing to know. Minimizing change impact is often positive.

How is this more limited change affecting possible future syntax usage of commas for tuples? :-)

Bye,
bearophile

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

If we kill this, it should be killed properly. I fear that we'll end up with some sort of half-dead zombie syntax like C-style array declarations.

http://d.puremagic.com/issues/show_bug.cgi?id=953

On 3/23/14, 8:30 PM, bearophile wrote:
> How is this more limited change affecting possible future syntax usage
> of commas for tuples? :-)

The change has an eye to that. Disallowing the use of the return value offers us the future possibility of redefining it. -- Andrei

On 3/23/14, 8:58 PM, Brian Schott 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
>
> If we kill this, it should be killed properly. I fear that we'll end up
> with some sort of half-dead zombie syntax like C-style array declarations.
>
> http://d.puremagic.com/issues/show_bug.cgi?id=953

The comparison doesn't hold. -- Andrei

On 3/23/14, 8:22 PM, Etienne Cimon wrote:
> How about allowing it only inside parenthesis?

That works but breaks more valid code. -- Andrei

Brian Schott:

> http://d.puremagic.com/issues/show_bug.cgi?id=953

This is off-topic in this thread. But I think just disallowing mixed C/D declarations is a step forward:
http://d.puremagic.com/issues/show_bug.cgi?id=5807

I mean code like:

int[] a[];

Bye,
bearophile

On 2014-03-24 00:04, Andrei Alexandrescu wrote:
> On 3/23/14, 8:22 PM, Etienne Cimon wrote:
>> How about allowing it only inside parenthesis?
>
> That works but breaks more valid code. -- Andrei
>

If the comma expression operator is outlawed on the global scope, variadic template parameters could be used with commas outside the parantheses which allows such syntax:

if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR
return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR
if(e!pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // OK
return e!pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // OK

Would it make sense to reserve the global e identifier for expressions?

I'd be happy to see commas go and eventually wake up to this in a few years, also enabling what would seem like a new kind of comma operator overloading

On 3/23/14, 9:29 PM, Etienne Cimon wrote:
> On 2014-03-24 00:04, Andrei Alexandrescu wrote:
>> On 3/23/14, 8:22 PM, Etienne Cimon wrote:
>>> How about allowing it only inside parenthesis?
>>
>> That works but breaks more valid code. -- Andrei
>>
>
> If the comma expression operator is outlawed on the global scope,
> variadic template parameters could be used with commas outside the
> parantheses which allows such syntax:
>
> if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR
> return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR
> if(e!pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // OK
> return e!pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // OK
>
> Would it make sense to reserve the global e identifier for expressions?

With that the approach would be veering off the road. -- Andrei

On 2014-03-24 00:41, Andrei Alexandrescu wrote:
> On 3/23/14, 9:29 PM, Etienne Cimon wrote:
>> On 2014-03-24 00:04, Andrei Alexandrescu wrote:
>>> On 3/23/14, 8:22 PM, Etienne Cimon wrote:
>>>> How about allowing it only inside parenthesis?
>>>
>>> That works but breaks more valid code. -- Andrei
>>>
>>
>> If the comma expression operator is outlawed on the global scope,
>> variadic template parameters could be used with commas outside the
>> parantheses which allows such syntax:
>>
>> if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR
>> return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR
>> if(e!pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // OK
>> return e!pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // OK
>>
>> Would it make sense to reserve the global e identifier for expressions?
>
> With that the approach would be veering off the road. -- Andrei
>

Well, I'll vote for the compromise, there shouldn't be issues with keeping statements in void contexts such as
int i, j, k;
i++, j++, k--;
etc.

And then I guess I'll change that part of my coding style, everyone seems to hate it so much ..