Thoughts on possible tuple semantics

[Andrei Alexandrescu]

On 8/21/13 8:22 AM, Dicebot wrote:
> Inspired by recent syntax thread I decided to write down by vision of
> how native language tuples should behave and how it may integrate into
> existing language state.

Awesome!

> Define two distinct built-in "tuples":
[snip]
> In further examples I will use imaginary syntax:
>      ctseq(int, string, 42) : template argument sequence
>      tuple("one", 2, three) : value tuple
>
>>>>>>
>
> // connections to existing template syntax
>
> void foo(T...)(T args)
> {
>      static assert(is(T == ctseq(int, string)));

There's going to be significant difficulty with this. This would be much 
easier:

       static assert(is(ctseq(T) == ctseq(int, string)));

Right now "T" as above has no type of its own, and ascribing a type to 
it would be a major change to which I think it's impossible to retrofit 
existing code without some breakages. If "T" is a type then "args" has a 
type and then we're back to asking ourselves whether writeln(args) 
passes one argument or more to writeln.

I do agree that we could take a different route if we designed the type 
system today, but we aren't. Current design is a legacy/liability.

>      static assert(is(typeof(args) == T));
>      assert(args == tuple(1, "2"));

So it seems the relationship between ctseq and tuple is that 
typeof(tuple(x, y. z)) is ctseq(typeof(x), typeof(y), typeof(z)). This 
leaves out of the discussion things like ctseq(1, "2") which contain 
compile-time values, not types. In that regard I'd prefer the two being 
entirely distinct.



Andrei