Tuple/TypeTuple etc.

[John Colvin]

Denis has been complaining about this for ages and I think it's 
worth doing something about.

Definitions:

std.typecons.Tuple
A bit like python's tuples. It's a heterogeneous collection of 
runtime values with compile-time determined types.

std.typetuple.TypeTuple
A heterogeneous *compile-time* collection of types, expressions 
and aliases.


Problems:

TypeTuple isn't just a typetuple, it's an everythingtuple. It's a 
terrible name that is confusing to newcomers (and even to people 
who've used D a lot but not delved in to the CT capabilities so 
much).

TypeTuple looks too much like Tuple. It's a totally different 
concept but the names are too similar.


Possible solutions:

1) rename TypeTuple in-place to something better. This is not a 
real option as it would break far too much code.

2) Introduce a new tuple constructor with a new name, and 
deprecate TypeTuple

2a) A whole new module, leaving std.typetuple as effectively an 
alias to the new module. Denis has a pull for this[1], which also 
adds new tuple constructors specialised for expressions.


I like Denis' pull request. It fixes the problem in a backwards 
compatible manner. However - as Jonathan points out in the 
comments - the naming is still a problem. GenericTuple, 
ExpressionTuple etc. all sound like they could be related to 
std.typecons.Tuple

So, we need a new name:
Sequence, ArgList or ParamList are possible suggestions.


A possible complete path to getting this sorted, using Sequence 
as an example:

1) Create a new module like in Denis' PR, called std.sequence and 
containing the template Sequence, equivalent to current 
std.typetuple.TypeTuple

1a) optional: include specific templates like TypeSequence and 
ExpressionSequence.

2) Leave std.typetuple as an alias to the new module, including 
alias TypeTuple = Sequence; Deprecate it.

3) std.traits.isTypeTuple becomes isTypeSequence and 
isExpressionTuple becomes isExpressionSequence.   Deprecated 
aliases from the old names are left for compatibility.

4) Change phobos over to using std.sequence (note that this is 
not required immediately, as there is 100% backwards 
compatibility).

The only remaining headache would be people getting confused by 
dmd spewing out complaints about tuple(blah, blah, blah), but 
that's a relatively minor concern.


P.S. please note that deprecating is not breaking, per se. 
Deprecations are just warnings by default. Also, although having 
compatibility aliases floating around is annoying, it's an 
unfortunate necessity if one wants to change things while not 
breaking everyone's code. I think it's a model we're going to 
have to get used to in order to be both flexible and reliable.

[1] https://github.com/D-Programming-Language/phobos/pull/780