Should the comma operator be removed in D2?

[Bill Baxter]

On Mon, Nov 16, 2009 at 2:04 PM, Justin Johansson <no at spam.com> wrote:
> Mentioned in the switch case statements thread, this probably should be a
> separate discussion thread.
>
> Is the comma operator "another piece of C cruft" that needs to be removed
> from D(2)?
>
>
> grauzone wrote:
>> Justin Johansson wrote:
>>> bearophile wrote:
>>>> What's bad about forcing people to write:
>>>> case A, B, C:
>>>>
>>>> Instead of:
>>>> case A:
>>>> case B:
>>>> case C:
>>>> ?
>>>>
>>>> Bye,
>>>> bearophile
>>>
>>> I don't know about "forcing people" to write such but perhaps it could
>>> be an "option for people" :-)
>>>
>>> Actually I quite like the brevity you propose but would it be a
>>> challenge for the comma operator?
>>>
>>> While ago, I got D multi-dimensional array syntax messed up and
>>> declared such an animal as
>>> int[3,4,5] which effectively ended up declaring the beast as int[5].
>>
>> The comma operator is another piece of C cruft that needs to go.


Note that if comma-as-sequencer was removed, and repurposed as a tuple
literal  (with "a,b"  making a tuple), and if we specify that tuple
elements are evaluated in order, then I think this would work as a
replacement for the current comma operator:

  (expr1,expr2,expr3)[$-1]

But the nice thing is you can get the effect of a comma operator that
evaluates to the value of any expression in the sequence, just using
different indices.
Not sure how odious people would find forcing an order of eval on
tuples, though.

In the context of a for-loop, you don't care what the value is, so it
would work as a tuple as-is.  The tuple itself would be the value:

  for(; i<10; ++i,++j)  // just works

Though, probably this case needs some special treatment to continue working:

  int i=0,j=0

--bb