Thoughts on possible tuple semantics

[deadalnix]

First, thank you so much ! The previous discussion was going 
nowhere as too much focused on syntax.

On Wednesday, 21 August 2013 at 15:22:59 UTC, Dicebot wrote:
> Define two distinct built-in "tuples":
>
>     - Template argument sequence: may contain anything that is 
> legal template
>         argument.
>     - Value tuple or simply "tuple": may contain any values, 
> including run-time
>     values. Value storage location is not defined.
>
> Template argument sequence that contains only types is called 
> "type sequence"
> and is considered a type on its own. Type of value tuple is a 
> type sequence.
>

Good let's drop tuple for sequence, that is much, much better. 
However, as sequence works now, it won't fit for the type of a 
tuple, as it auto expand.

> Each of these two entities has its own literal type. This is 
> required to avoid
> ambiguity between storing symbol as a type and taking its value 
> on run-time. Tuple
> always does the latter.
>
> In further examples I will use imaginary syntax:
>     ctseq(int, string, 42) : template argument sequence
>     tuple("one", 2, three) : value tuple
>

I have some syntax suggestion, but let's keep that for later. 
Semantic first.

> ----- (auto) expansion / packing / unpacking -----
>
> As Andrei has stated clearly that he does not like 
> auto-expansion and considers
> it a major mistake, I was trying to imagine how that idea can 
> be incorporated
> into idiomatic D code.
>

That is the hard point, clearly. This has advantages, but 
difficult to make everything fit together.

>>>>>> 
>
> // existing syntax
>
> // args can't be single entity and use normal parameter passing 
> ABI at the same
> // time.
>
> void foo(T...)(T args) // following normal ABI implies unpacking
> {
> }
>
> foo(1, 2, 3); // automatic packing
>

Which mean that I can call foo with a tuple directly ? What about 
:
auto a = tuple(1, 2);
foo(a, 3);

I guess this is the pack/unpack issue again.

> ----- std.typetuple.TypeTuple / std.typecons.Tuple -----
>
> No need to keep them other than for backwards compatibility ;)

Nobody understood them anyway.