Should the comma operator be removed in D2?

[Bill Baxter]

On Tue, Nov 17, 2009 at 6:06 AM, Leandro Lucarella <llucax at gmail.com> wrote:
> Ellery Newcomer, el 16 de noviembre a las 19:02 me escribiste:
>> Justin Johansson wrote:
>>
>> > Great. Sounds like problem solved in that there is no problem.
>> >
>> > So how do people feel about bill's suggestion to progress the issue
>> > further?
>> >
>> > Be good to get some comments from higher-up (Walter, Andrei)?
>> >
>> > Predict bearophile will chime in on this one too?
>>
>> The real problem is you'd end up with a tuple syntax identical to a
>> valid c syntax. If D silently accepts it, but does something different,
>> it's a no go.
>
> Code ported from C should not compile if the comma expression is converted
> to a tuple literal because if a and b are int, typeof(a,b) is int now and
> will be Tuple!(int, int) in the future, and I don't think
> a Tuple!(anything) could be implicitly casted to anything, except, maybe,
> another tuple, but you don't have tuples in C, so there is no risk on that.

Good point!  A trick like this:

    if (ok=func1(), b=func2(), ok)  { ... }

Will not compile if that's an (int,int,int) tuple.  Brilliant.  So
anywhere you're actually using the value in C is covered, it'll be an
error in D.

And for places where you're not using the value, it'll do the right
thing as long as we define the order of evaluation to be left to
right.
I think Walter wants to have the evaluation order for most everything
defined in D, anyway.  Just to avoid having implementation-defined or
non-deterministic behavior.

--bb