DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Timon Gehr]

On 09/24/2012 12:57 AM, Andrei Alexandrescu wrote:
> On 9/23/12 6:42 PM, Timon Gehr wrote:
>> That is because it does not base the discussion on the right
>> limitations of built-in tuples:

Actually that is mostly unrelated to the comma operator. Apologies.

>>
>> auto (a,b) = (1,"3");
>> (auto a, string b) = (1, "3");
>
> I meant to mention that but forgot. The interesting thing about this is
> that, if we decide it's the main issue with today's tuples, we pull
> Kenji's patch and close the case.
>

Imho, it certainly is the main issue.

> ...
>> - We already use the name 'tuple'. I'd suggest renaming that to
>> 'sequence' or similar. template Seq(T...){ alias T Seq; }
>
> Then what are the "old" tuples?
>

Instances of TypeTuples, eg:

template Seq(T...){ alias T Seq; }
Seq!(int, double) foo(){ }

=> "Error: functions cannot return a tuple"

>> - The empty tuple can well be (), just like 'Seq!()' works without
>> issues (it is an expression that is also a type). What is wrong with
>> it?
>
> There's already intensive use of parens in D. I predict there's going to
> be big trouble with "()" even assuming it's not technical ambiguous,

Well, (,) cannot help with that.

> for
> example a lambda that returns an empty tuple would be "()() {...}" and
> all that jazz.

Well, it would be ()=>() or delegate()()=>(), but is it even reasonable
to use the second form?

>
>> - How do we expand a sequence into a tuple?
>> => (Seq!(1,2,3),)
>
> I think we're discussing different things - the above seems to deal with
> expression/alias tuples. DIP19 discusses strictly runtime value tuples.
>

I am discussing the interplay of the two features. Sequences are 
auto-expanded in all contexts where it makes sense (except if they
happen to be the second argument to a comma expression, then they are
not, but I assume that is a bug.)

I expect the following to be equivalent:

(Seq!(1,2,3),)

and

(1,2,3)

>> - What is the calling convention used for passing built-in tuples to
>> and from functions?
>
> I don't know. The current approach with .expand is nothing special - as
> if the programmer wrote the expansion by hand.
>

Not sure we are on the same page. I meant the calling convention at the
ABI level.

>> - As tuples are built-in, expansion can be shorter than '.expand'.
>> foo(1, tup..., 3); ?
>
> I find that sugar gratuitous.
>

You find built-in tuples gratuitous in general. :o)
Anyway, it certainly is not necessary.

>> - Template tuple parameters? This would work, but...
>> template Tuple((T...,)){ alias (T,) Tuple; }
>>
>> void bar(T,(U...,),V...)(T delegate(U) dg, V args){ ... }
>> void foo(T,(U...,),(V...,))(T delegate(U) dg, V args){
>> bar!(T,Tuple!U,V)(dg, args);
>> } // U and V can be passed separately
>>
>> - Named tuple fields?
>>
>> (int x, int y) tuple = (1,2);
>>
>> swap(tuple.x, tuple.y);
>
> I kinda got lost around all that.
>

I assume named tuple fields are not a problem?
Other than that, I raised the issue of how to match and destructure
tuple types in template parameter lists. And came up with the following
proposal, which I do not like.

template Foo((U...,)){ alias (U,) Foo; }

void main(){
     (int, double) x;
     Foo!(typeof(x)) y;
     static assert(is(typeof(x)==typeof(y)));
}