On Tuesday, 20 August 2013 at 00:29:17 UTC, H. S. Teoh wrote:
Sounds like you're confused about what built-in tuples are (and
you wouldn't be the first -- they're rather confusing things).
I know the difference between std.typecons.Tuple and the built-in
tuples. What I'm confused about is I thought that the main
objective of the tuple literal syntax (destructuring/pattern
matching aside) was a means to have first-class tuples. That is,
tuples that have their own literal syntax, have a list of valid
operations that can be done on them, can be passed to functions,
and can be returned from functions.
Whether this is implemented as a syntactic sugar for
std.typecons.Tuple, syntactic sugar for the built-in tuples, or a
primitive type analogous to int, char, double[], etc. is not
particularly important. It's becoming clear, now, that everyone
has a different idea about what tuples should comprise, and I
believe I have a better understanding of why this issue has yet
to be solved.
The answer is, this code makes no sense, because you can't
return
template arguments from a function. It makes as much sense as
returning
a function's signature from a function. You can't do that,
because a
function's signature isn't a runtime value that can be returned.
Similarly:
return TypeTuple!(int, 1);
doesn't really make sense. The tuple (int, 1) isn't a runtime
value that
you can return from a function. It's a compile-time concept
that doesn't
exist at runtime.
All which makes it not first-class.
Let's return, then, to Kenji's DIP, and ask how the semantics he
described can be implemented in D, unless someone objects to some
facet of the DIP, at which point it can be worked out.
