DIP54 : revamp of Phobos tuple types

[Jakob Ovrum]

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.