This is the reason I had originally thought Kenji's DIP was about
run-time tuples. If it's just syntactic sugar over
std.typecons.Tuple (plus some extra destructuring/pattern
matching stuff), it would require no ABI changes and no changes
to TypeTuple semantics. The one thing it wouldn't do is unify
Tuple and TypeTuple.
However, with compiler support, we can make this situation
better. TypeTuple stays as-is, while Tuple becomes a value
instead of a type, which has its own literal syntax. This means
that typeof(tuple(1, "a")) is not Tuple!(int, string), as in the
struct, but TypeTuple!(int, string), as in the compiler tuple.
You could still do all the stuff that can be done with TypeTuple
currently, but it should be strongly discouraged to mix types and
values within TypeTuple, or even limited by the compiler. This
creates a clear distinction between runtime tuples and TypeTuple.
It becomes much easier to reason about their semantics, as we can
think of TypeTuple as a type, just like int, string, double,
etc., and Tuple as a value, just like 1, "a", 2.3, etc. The only
difference between TypeTuple and regular types is that there are
a few special static operations that can be used to manipulate
it. Otherwise it behaves as a type.
