Tuple/TypeTuple etc.

[John Colvin]

On Friday, 16 August 2013 at 16:03:22 UTC, John Colvin wrote:
> 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

How do you guys feel about ctList/CtList/CTList?