Discussion of TypeTuple naming

[Denis Shelomovskij]

27.05.2013 15:36, Diggory пишет:
> 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.

Good luck from the heart as I've failed with almost every proposal to 
change/add something in Phobos or in a language. For generic tuple 
lovers (like me) I'd suggest just to use my `unstd.generictuple` [1] as 
it has rather good code quality and I will keep it up-to-date with 
language changes.

[1] http://denis-sh.github.io/phobos-additions/unstd.generictuple.html

-- 
Денис В. Шеломовский
Denis V. Shelomovskij