Should the comma operator be removed in D2?

[retard]

Tue, 17 Nov 2009 14:38:57 -0800, Bill Baxter wrote:

>> I agree, a tuple of one element (doesn't matter what type, array in
>> this case) should be semantically identical to that single element.
>>
>> proper semantics for language supported tuples should IMO include: 1)
>> syntax to explicitly [de]construct tuples and no auto-flattening 2) a
>> tuple of one element is identical to a scalar:
>>   int a = 5; // scalar integer
>>   auto b = (5); // tuple of one integer a == b // is true
> 
> Interesting.  It does kinda make sense.  So should indexing work too?
> And properties?  5[0] == 5?  5.length == 1? If not that could be painful
> for functions that process generic N-tuples. If so then what does that
> do if the "scalar" type happens to be float*?

In some languages () is a distinct Unit type. Tuples are defined 
recursively from the Pair type, e.g. Pair[int,int], Pair[int, Pair
[int,int]] === (int,int,int). And have a special indexing syntax with 1-
based indexing.

> 
>> 3) function's argument list is a tuple like in ML:
>>   void foo(int a, char b);
>>   int a = 5; char b ='a';
>>   auto tup = (5, 'a');
>>   foo(a, b) is identical to foo(t);

Tuples can't encode things like by-ref, by-val, lazy etc.

> That seems like a kind of auto-flattening.  Shouldn't (t) be a tuple of
> a tuple?
> What if you have an actual tuple in the signature, like void foo((int
> a,char b))?
> Or you have both overloads -- foo(int,char) and foo((int,char)) I think
> I like Python's explicit "explode tuple" syntax better.
>    foo(*t)

> Probably that syntax won't work for D, but I'd prefer explicit
> flattening over implicit.

Good boy.

> 
>> 4) unit type defined by the empty tuple instead of c-like void
> 
> This is kind of neat, but does it actually change anything?  Or just
> give an aesthetically pleasing meaning to void/unit?

The empty tuple can be considered to be the unit type.