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?
