On Monday, 24 March 2014 at 04:00:14 UTC, Andrei Alexandrescu wrote:
> 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

That is brilliant ! I'm buying.

deadalnix:

> Andrei Alexandrescu:
>> The change has an eye to that. Disallowing the use of the return value offers us the future possibility of redefining it. -- Andrei
>
> That is brilliant ! I'm buying.

Please show few examples. I am not sure using the comma for tuples in just return situations is a good idea. It seems too much special casing. Also because returning tuples is already currently acceptable. The main problem is breaking tuples apart.

Bye,
bearophile

On Monday, 24 March 2014 at 05:18:04 UTC, bearophile wrote:
> deadalnix:
>
>> Andrei Alexandrescu:
>>> The change has an eye to that. Disallowing the use of the return value offers us the future possibility of redefining it. -- Andrei
>>
>> That is brilliant ! I'm buying.
>
> Please show few examples. I am not sure using the comma for tuples in just return situations is a good idea. It seems too much special casing. Also because returning tuples is already currently acceptable. The main problem is breaking tuples apart.
>

I actually made a more complete explanation of what I have in mind. I should probably write a DIP one day.

You can read a rough explanation of my proposal here:
http://forum.dlang.org/thread/lrycaqlrtwylhbxfifyz@forum.dlang.org?page=2#post-mudvqeqzbosfdirtfkhr:40forum.dlang.org

"Adam D. Ruppe"  wrote in message news:kuyoqpmqvevpkpzdxsxq@forum.dlang.org...

> > 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.

lazy void 

On Monday, 24 March 2014 at 01:28:02 UTC, Kenji Hara wrote:
>     if (cond) exp1, exp2;   // in most case, this is not a bug.

I fail to see how is this useful. It looks way harder to comprehend, because first you have to recognize a comma operator has been used (rare), and then you have to understand why it was used (and it's always avoidable).

If using C++, such a code would trigger a static analyzer warning.

On Monday, 24 March 2014 at 02:31:46 UTC, Andrei Alexandrescu wrote:
> On 3/23/14, 7:21 PM, Kenji Hara wrote:
>> At least I can imagine two reasonable cases.
>>
>> 1. If the code is ported from C/C++, breaking it is not reasonable.
>>
>> 2. If the two expressions are strongly related, using comma operator is
>> reasonable to represent the intensity. I think rather it's an *ability*
>> to represent code meaning by using code style.
>>
>> Kenji Hara
>
> One concession we could make would be to disallow using the result of the operator. That might actually catch all bugs discussed herein.
>
> if (condition) ++i, ++j; // fine
> foreach (e; exp1, exp2) {}   // ERROR
> if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR
> return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR
>
> I think this would be a compromise worth looking into.

I like it a lot. Almost *all* the "abusive" uses of "operator comma" I've seen use this trait of operator comma. So this would kill those:
//----
auto a = fun(), 5; //WTF is wrong with you?
//----

On the other hand, the "legit" cases of comma never seem to use the return value. The "only" execute two statements in a single context. For example:

//----
for (size_t i, j ; someCondition() ; ++i, ++j )
{...}
//----

I think this is *the* single most common use of operator comma, and I also think it is perfectly legit. Sure, it can easily be migrated away from, but I think it would be gratuitous breakage of good code.

--------

So this has my +1 vote.

On Sunday, 23 March 2014 at 22:03:03 UTC, John Colvin 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
>
> Kill it. Eventually we may be able to reclaim it as something more useful.


There are some well reasoned arguments for keeping it expressed in this thread. I would personally be happy with Andrei's compromise.

On Monday, 24 March 2014 at 09:09:30 UTC, monarch_dodra wrote:
> //----
> for (size_t i, j ; someCondition() ; ++i, ++j )
> {...}
> //----
>
> I think this is *the* single most common use of operator comma, and I also think it is perfectly legit. Sure, it can easily be migrated away from, but I think it would be gratuitous breakage of good code.

Legit but largely useless.
In every cases I've seen where this idiom appears, you can derive j from i and the compiler is able to generate the very same code.

On Monday, 24 March 2014 at 09:13:39 UTC, ponce wrote:
> On Monday, 24 March 2014 at 09:09:30 UTC, monarch_dodra wrote:
>> //----
>> for (size_t i, j ; someCondition() ; ++i, ++j )
>> {...}
>> //----
>>
>> I think this is *the* single most common use of operator comma, and I also think it is perfectly legit. Sure, it can easily be migrated away from, but I think it would be gratuitous breakage of good code.
>
> Legit but largely useless.
> In every cases I've seen where this idiom appears, you can derive j from i and the compiler is able to generate the very same code.

I've seen plenty of cases where you can't, such as most algorithms that "copy filter" or "copy remove". Further, especially with ranges, you can't derive one from the other. The code usually becomes:

for ( ; someCondition() ; r1.popFront(), r2.popFront() )

On Mon, 24 Mar 2014 02:50:17 -0000, Adam D. Ruppe <destructionator@gmail.com> wrote:
> int a = something == 1 ? 1
>        : something == 2 ? 2
>        : (assert(0), 0);

FWIW I personally find this kind of code horrid.  I would re-write to:

assert  (something == 1 || something == 2);
int a = (something == 1 || something == 2) ? something : 0;

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/