comma operator causes hard to spot bugs

[Era Scarecrow]

On Saturday, 21 April 2012 at 16:54:49 UTC, bearophile wrote:
> Jonathan M Davis:
>
>> There have been discussions about the comma operator before. I 
>> don't expect that it's going anywhere,
>
> Maybe there are intermediate solutions between keeping wild 
> commas in D and disallowing them fully. I think most of my bugs 
> caused by commas are similar to the one shown by the OP. This 
> means this is not a common source of bugs:
>
> foo(), bar();
>
> While this is sometimes a trap:
>
> auto x = foo(), bar();
>
> So maybe it's enough to disallow using the last expression of a 
> comma sequence as result of the whole expression? I don't know. 
> I almost never use commas for such purposes. What are the use 
> case for those commas?

  Well here's my two cents. Commas should only be used to separate 
parameters, and one exception to this is in for and foreach where 
they have specific purposes. With the way automatic type 
detection I would say instead remove them entirely. For the few 
for cases where you need multiple commands, use a block statement 
instead.

  for(; c < x.length; c++, othercommands)
becomes
  for(; c < x.length; {c++; othercommands;})

Actually seeing that you know the last block is together within 
the {}'s. Could also add that for the init part, but not the 
conditional. Course if it had to return something, then 'return' 
could be applicable. No return, then it's automatically type void.

//TDPL pg 61
int a = 5
int b = 10
int c = (a = b, b = 7, 8);

becomes:

int c = {a = b; b = 7; 8;};
int c = {a = b; b = 7; return 8;};

int[] x;
foreach(i, val; x) //still applicable, but only real case now 
that i can think of.

  Like this it looks less like a function call and a scope 
instead; but still returns something from a scope as it's return 
value. Although then it's almost a lambda function, except 
without calling parameters. Mmm thoughts?