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?
