March 24, 2014
Here's another.
https://d.puremagic.com/issues/show_bug.cgi?id=2659

Also, kill it with fire.

I do use it, but only in incomprehensible C++ algorithm competitions, where it saves a few strokes. Everywhere else it has only been a nasty surprise.
March 24, 2014
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.


Andrei

March 24, 2014
On Monday, 24 March 2014 at 02:12:20 UTC, Adam D. Ruppe wrote:
> On Monday, 24 March 2014 at 01:48:15 UTC, Daniel Murphy wrote:
>> Try it on your code, you might be surprised!
>
> hmm, I am surprised about one thing: it didn't detect a single use of the comma operator in the ~10,000 lines of my code I fed it. I know I don't use it often, but I thought surely there'd be at least one or two uses in all that!
>

I think I've never used this. Seriously. Not even in PHP. To me it always a horrible thing.
March 24, 2014
On Monday, 24 March 2014 at 02:21:20 UTC, Kenji Hara wrote:
> 2014-03-24 10:38 GMT+09:00 Daniel Murphy <yebbliesnospam@gmail.com>:
>
>> "Kenji Hara" <k.hara.pg@gmail.com> wrote in message
>> news:mailman.27.1395624482.25518.digitalmars-d@puremagic.com...
>>
>> 2014-03-24 10:09 GMT+09:00 bearophile <bearophileHUGS@lycos.com>:
>>
>>      if (cond) exp1, exp2;   // in most case, this is not a bug.
>>>
>>
>> It's not a bug, but this does the same thing - so why use the comma
>> operator?
>>
>> if (cond) { exp1; exp2; }
>>
>> It catches bugs that are otherwise very difficult to spot.
>>
>
> At least I can imagine two reasonable cases.
>
> 1. If the code is ported from C/C++, breaking it is not reasonable.

> Kenji Hara

What about the compiler make some effort to detect this usage and suggests the appropriated solution? just like it does when using C's array/cast style. i.e., split the expression separed by the comma operator in a list of expressions separed by semicolon inside a compund statement. It isn't too hard to implement.
March 24, 2014
On Monday, 24 March 2014 at 02:31:46 UTC, Andrei Alexandrescu wrote:
> 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.
>
>
> Andrei

That's a good idea. I never personally use the comma operator, as I think that it makes code less readable having multiple expressions evaluated on a single line. For the same reason, I almost never put multiple semicolon-delimited statements on the same line. Code like the above I find particularly egregious. It plays havoc with the programmer's expectation that they can parse the code left-to-right to figure out the result of an expression, forcing them to read in spirals. This is just as bad as the pointer declaration syntax for C/C++, just not as common.
March 24, 2014
"Andrei Alexandrescu"  wrote in message news:lgo5ei$1tne$1@digitalmars.com...

> 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 could live with that, although I'd still rather see it die. 

March 24, 2014
On Monday, 24 March 2014 at 02:31:46 UTC, Andrei Alexandrescu wrote:
> One concession we could make would be to disallow using the result of the operator. That might actually catch all bugs discussed herein.

If we go that far, we might as well just kill the whole thing, since half* the reason of using an expression in the first place is to use the result. Otherwise, you might as well use a statement.

if (condition) ++i, ++j; // might as well be { ++i; ++j; }

* The other half of the uses being where you want a statement, but the grammar won't allow it... but even in those cases, the ONLY time I can think of where this is the case AND you don't need the result is the increment expression of the for loop.

So with that compromise, it is equivalent to banning the comma expression except in the special case of the for loop and in code that has no real reason to use it in the first place (and is also the most likely place where it was used unintentionally).

** Concrete example of where I (/very/ rarely apparently) consciously use the comma operator:

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

There, I want the assert(0) to trigger in the default case, but the ternary operator still needs a value to assign to the variable a, so the ,0 provides that. Never actually used, but required for the common type of the ternary to match up.
March 24, 2014
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.
>
>
> Andrei

I could live with that too but I suggest to extend if(condition) to allow assignment too:

if(condition) x = 2, y = 3; // fine
if(condition) f(),x=3; // ERRROR

What do you think?
March 24, 2014
From what I see on Wikipedia(http://en.wikipedia.org/wiki/Comma_operator) Go language has no comma operator.
March 24, 2014
On Monday, 24 March 2014 at 02:50:18 UTC, Adam D. Ruppe wrote:
> (and is also the most likely place where it was used unintentionally).


Actually, this is overreaching, the if(function(call), misplaced) is probably the most likely place it is used unintentionally.

But still, if we make this change at all, I see no reason to keep if(a) b, c; given the extreme rarity of that case and the ease with which i can be replaced with if(a) { b; c; }

I'd prefer to remove it entirely over keeping this compromise.