Should the comma operator be removed in D2?

[Bill Baxter]

On Tue, Nov 17, 2009 at 3:57 PM, retard <re at tard.com.invalid> wrote:
> 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.

That wasn't really the question.  It was what should 5[0] do in D, if
scalars are considered to be 1-tuples?
I think that's a killer for 1-tuple / scalar equivalence in D.
Neither behavior is acceptable in my opinion.
So it seems you can't have 1-tuple/scalar equivalence unless you have
a distinct tuple-indexing syntax.

Right now std.typecons.tuple uses x.at!(0) because you can't have a
x[i] return different types, but the built-in "A..." template tuples
do it.
So that's something that needs to be fixed anyway, because "good for
me but not for thee" is lame.  (Took that phrase from a review of
Go...)
I think probably D should allow a templated opIndex!(int) so that user
types can implement tuple-like indexing where each index could be a
different type.

Or we should try to come up with another syntax for indexing tuples.


>>> 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 does seem to kill that idea.


>> 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.

Yes, Yigal said basically that.  The question I have is what practical
difference does that make to the language?
Seems no different from defining the empty tuple to be void, then
renaming void to unit.


--bb