I think this is just getting absurd.
The conflation between the naming issue and auto-expansion is so
bloody dishonest. The DIP looks really good to newbies because it
addresses the former but then they don't really understand the
latter (as some have even said explicitly). Further, if this DIP
had been discussed in *public* earlier, we could've handled this
then, which could've resulted in an earlier resolution of the
naming issue. I was genuinely wondering what was holding up the
situation. Sigh.
The most important thing here is that std.typecons.Tuple is
(conceptually) completely unrelated to std.typetuple.TypeTuple
and other cases of the "tuple" name used to refer to template
argument lists. This fact, compounded with insufficient and
confusing documentation, causes the difficulty of learning. We
can easily rectify this situation without any significant
overhaul of Phobos' utility templates, which are mostly good as
it is.
Then there is the separate issue of non-auto-expanding lists,
necessary for algorithms that take a variadic number of variadic
lists *that can contain types*[1]. I've been writing pretty heavy
meta-programming code using template argument lists extensively
since D1, and I've never required such an algorithm[2]. I've also
taught new D programmers about template argument lists for years
on IRC (including Dicebot), which is why I feel so strongly about
the naming issue.
So, we're proposing that we cause this massive, non-trivial code
breakage for the benefit of *who*, exactly? I have a feeling that
if this is pushed through, disgruntled programmers who regard
auto-expansion amicably will define their own substitutes for the
previous infrastructure, which is much nicer to work with than
the one proposed by this DIP, and much more in tune with the
underlying language feature, *that people will still have to
learn about*.
If a case for "packed lists" can be made, please make it
separately.
[1] The distinction is necessary, because if only non-types are
involved, CTFE + toTypeTuple(-ish) templates solves it, often
very nicely.
[2] That's not to say that I think they don't exist - I know they
do; but they are extremely niche. On the other hand, requiring a
*fixed* number of variadic lists pops up now and then, and is
trivially accomplished by using nested templates.
