tuple sumlimation

[Reiner Pope]

Kevin Bealer wrote:
> Currently, Tuples are sublimated into argument lists.  What do people 
> think of using an operator (say, *) to prevent this?  The reason I ask 
> is that the current technique makes it hard to pass multiple tuples on 
> the same function call.
> 
> I think it's not absolutely required; currently you can pass the tuple 
> lengths, let the tuples melt together, and then split them with slicing.
> 
> Kevin
How about expressing tuples as arrays? I mean, that's what they act as, 
and the features they support are array features: length, indexing, and 
a long-winded form of concatenation. Explicitly using them as arrays 
also allows for code reuse with already-existing array manipulation 
functions/templates.

So, regular tuples are just alias[], and type tuples could be typeid[] 
or even TypeInfo[]. You keep the old ... syntax (with implicit 
concatenation) and introduce a new one which supports alias[] and 
TypeInfo[] as template parameters. You could get the following (and 
equivalent forms for alias[]):

void writefln(T...)(T t) {...} // old syntax
void writefln2(TypeInfo[] T)(T t) {...} // new syntax -- no advantage here

template Foo(T...) {...}
template Bar(TypeInfo[] T) {...}

template Baz(TypeInfo[] T, TypeInfo[] U) {
     Foo!(T, U); // implicit concatenation, so we don't break old behaviour
     Bar!(T, U); // error: no implicit concatenation in new behaviour
     Bar!(T); // ok
     Bar!(T ~ U); // explicit concatenation still allowed
}

template Bam(T...)
{
     Foo!(T, T); // implicit concatenation, like before
     Bar!(T ~ T); // T is actually TypeInfo[], so concatenation syntax 
permitted
     Baz!(T, T); // No implicit concatenation
}


It shouldn't break existing code, but it should support nesting (by 
disallowing implicit concating), as well as more code reuse.

Cheers,

Reiner