I gather this has been discussed before and even a potential
solution submitted
(https://github.com/D-Programming-Language/phobos/pull/780)
However it was dismissed due to too much existing code being
broken.
I'd like to suggest a slightly less severe change which should
still fix the issues with TypeTuple:
https://github.com/D-Programming-Language/phobos/pull/1309
It introduces a new template, StaticTuple which can store any
template parameters. The two templates are exactly equivalent
except that TypeTuple checks that its parameters are actually
types, so StaticTuple!(int, float) == TypeTuple!(int, float).
Reasons for the change:
- Tuples seem to confuse everyone trying to learn D, the
inconsistency in TypeTuples is a big part of that. Naming the new
type "StaticTuple" makes it abundantly clear that the built in
"Tuple" type is for storing multiple values together at runtime
while a "StaticTuple" is a similar construction but for compile
time. It then follows directly that "TypeTuple" is a particular
type of "StaticTuple" for dealing with types.
- The current functionality of using TypeTuples with non-types is
extremely useful and yet completely undocumented. This change
means that if some code expects a StaticTuple we can be safe to
assume that passing it non-types will be fine, and it also opens
of the doors for other specialized versions of StaticTuple such
as ExpressionTuple. I have avoided doing anything other than the
most basic addition of StaticTuple in this pull request as
further improvements are a separate issue that can be dealt with
later.
- Unless we plan to stick to the current absurd and confusing
naming for TypeTuple forever, it's better to make the change
sooner rather than later.
Reasons why this change is not detrimental:
- The result of the change is zero existing code actually failing
to compile. TypeTuple will simply show a deprecation warning if
used with non-types.
- If even a deprecation warning is too much an arbitrarily large
existing code-base can be fixed using a one off find and replace.
- The new template is also still in the "std.typetuple" module.
This is not ideal but it is also not a problem - it's common for
a module to contain related types in addition to the one it's
named after.
- Any code that does use non-types with TypeTuple is using
undocumented behaviour. Making undocumented behaviour deprecated
is a very reasonable change even in the most stable of languages,
so arguing that D is supposed to be stable and that this breaks
too much is not a very convincing argument.
- Almost all uses of TypeTuple are for dealing with types and so
will be completely unaffected by the change.
- There's no necessity to ever actually completely remove the
deprecated behaviour, the deprecation warning is enough. It's not
like code only has X amount of time to change its behaviour to
the new system.
