A Discussion of Tuple Syntax

[Dicebot]

On Tuesday, 20 August 2013 at 03:33:51 UTC, Kenji Hara wrote:
> Sorry I cannot reply to each thread comments quickly, so I 
> discharge my
> opinions at once.

One thing that I think does not get deserved attention is that 
built-in expression tuple are not limited to compile-time values. 
Lets consider this simple example:

void foo(T...)(T args)
{
	pragma(msg, args);
	pragma(msg, typeof(args));
}

void main()
{
	int a, b;
	foo(a, b);
}


-----------------------

/d147/f686.d(3): Error: variable _param_0 cannot be read at 
compile time /d147/f686.d(3): Error: variable _param_1 cannot be 
read at compile time tuple(_param_0, _param_1) (int, int)

-----------------------

What we have here are two completely different _built-in_ tuple 
types. "T" is pure template arguments list and is pretty much 
equal TypeTuple!(int, int). But what is "args"? It uses the very 
same built-in tuple syntax but it is much closer to 
std.typecons.Tuple in its behavior (actually, latter is 
implemented in terms of it as I was pointed out) - it is an 
entity that provides abstraction of top of group of run-time 
values. It does not have any binary structure on its own (built 
on top of existing values) but observable semantic are very 
"run-time'ish".

What bothers me is the question "can we clean this up and bring 
those two worlds together, even at cost of minor breakage?". I am 
not speaking about literals here or unpacking or whatever. I am 
speaking about re-defining semantics so that struct-based Tuple 
and built-in syntax sugar in form of run-time expression tuple 
both get merged into one built-in construct which can be used in 
wider variety of places.

At least right now I can't find any technical objections why 
expression tuple can't use std.typecons.Tuple ABI when returned 
from function but still be automatically expanded when passed 
into functions. Kenji, what is your your opinion about complexity 
to implement something like that in DMD?