www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Discussion of TypeTuple naming

reply "Diggory" <diggsey googlemail.com> writes:
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.
May 27 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 05/27/2013 01:36 PM, Diggory wrote:
 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 is not that similar, as it automatically expands into any context and hence does not allow a nested structure.
 It then follows directly that
 "TypeTuple" is a particular type of "StaticTuple" for dealing with types.

I don't think that having a construct that is restricted to just types makes a lot of sense.
 - 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.

TypeTuple does not implement any functionality. It is an 'identity function'.
 - 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.
 ...

The new name should be an improvement. Certainly shorter. I (and others) just use: template Seq(T...){ alias Seq = T; } As far as I am concerned, this won't change if the new name takes a substantial amount more space.
May 27 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/27/13, Diggory <diggsey googlemail.com> wrote:
 - 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.

You are forgetting about performance. TypeTuple can be used *a lot* in generic code. If you add static checking for each tuple element you're going to slow down the compiler quite a bit. And you won't know this if you only sporadically use TypeTuple.
 - Any code that does use non-types with TypeTuple is using
 undocumented behaviour.

It's not undocumented behavior, it's documented, e.g. The D Templates Book.
 - Almost all uses of TypeTuple are for dealing with types and so
 will be completely unaffected by the change.

Where do you get this clarity that it's only used for types? Have you inspected all D libraries out there?
 - There's no necessity to ever actually completely remove the
 deprecated behaviour, the deprecation warning is enough.

It's not, because now you're forced to always compile with the deprecation switch. --- All I see here is the problem with the actual *name* of the template. If it's so horrible to use this name, the simplest thing we can do is introduce an alias to TypeTuple, ala "Seq" or "ExpressionTuple", or something similar. Of course "TypeTuple" is a misnomer, but it's way too late to change it now or even change its semantics. Even slowing it down by doing type-checking is a problem.
May 27 2013
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, May 27, 2013 21:13:10 Andrej Mitrovic wrote:
 On 5/27/13, Diggory <diggsey googlemail.com> wrote:
 - There's no necessity to ever actually completely remove the
 deprecated behaviour, the deprecation warning is enough.

It's not, because now you're forced to always compile with the deprecation switch.

That's not true anymore. Deprecations only print out warning messages by default, precisely so that we can deprecate things without breaking everyone's code. -d makes the compile shut up, but it is no longer required to get your code to compile. That being said, I don't really like the idea of deprecating something with the intention that it stick around forever. It just provides a smoother transition.
 All I see here is the problem with the actual *name* of the template.
 If it's so horrible to use this name, the simplest thing we can do is
 introduce an alias to TypeTuple, ala "Seq" or "ExpressionTuple", or
 something similar.
 
 Of course "TypeTuple" is a misnomer, but it's way too late to change
 it now or even change its semantics. Even slowing it down by doing
 type-checking is a problem.

Yeah. The only problem I see is the name. I don't see any real benefit in making it so that we have _three_ different types of compile time tuples, particularly when their uses tend to be fairly localized rather than being passed around through APIs and the like (if they get passed through APIs, they'd just be template or function argument lists), and any mismatch of types and expressions will result in an error pretty much instantly. So, holding both expressions and types isn't really a problem IMHO - particularly since that's what the built-in tuples do, and all TypeTuple really is is a template to let you create and manipulate the built-in tuples. So, if we change anything, we change the name via an alias and leave all of the semantics alone. But given how much TypeTuple is used and that the module is named std.typetuple, it would likely have to be a permanent alias, in which case you _still_ have to explain what TypeTuple is, and the gain of renaming it is minimal IMHO (it could even make things _worse_ by increasing the confusion by having multiple names). The name sucks, but I think that we're stuck with it at this point. For it to be worth it, we'd have to be willing to force everyone to change their code to use the new name, and for the most part, we're just not doing that sort of thing anymore. - Jonathan M Davis
May 27 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
Please do not destroy the structure of the discussion. Answer different 
posts in different posts.

On 05/28/2013 12:23 AM, Diggory wrote:
 On Monday, 27 May 2013 at 13:42:51 UTC, Timon Gehr wrote:

 It is not that similar, as it automatically expands into any context
 and hence does not allow a nested structure.

The point being? It's true that there is some special behaviour, but that's the same regardless of whether it's called StaticTuple or TypeTuple.

The point being that both StaticTuple and TypeTuple are poor names.
 I don't think that having a construct that is restricted to just types
 makes a lot of sense.

In a language which is most emphatically statically typed

In a language that does not type check template bodies. Template metaprogramms are essentially untyped. Also, I can agree on statically typed, but not most emphatically statically typed. :o)
 with built in support for class invariants and in/out contracts

and static assertions and template constraints.
 you can't see the purpose of a TypeTuple?

Sure. It is rather pointless. The fact that there was a template constraint is not preserved or used for later type checking (inexistent) of the resulting "TypeTuple" in any way.
 TypeTuple does not implement any functionality. It is an 'identity
 function'.

And yet the documentation: http://dlang.org/tuple.html (see Type Tuples)

Sure.
 And the name clearly suggest that it DOES implement functionality
 - that of checking that the arguments are all types.

Sure. The name is the problem, even if I do not agree with your interpretation of the documentation. (there is not enough there to interpret.)
May 28 2013
prev sibling next sibling parent "Diggory" <diggsey googlemail.com> writes:
On Monday, 27 May 2013 at 13:42:51 UTC, Timon Gehr wrote:

 It is not that similar, as it automatically expands into any 
 context and hence does not allow a nested structure.

The point being? It's true that there is some special behaviour, but that's the same regardless of whether it's called StaticTuple or TypeTuple.
 I don't think that having a construct that is restricted to 
 just types makes a lot of sense.

In a language which is most emphatically statically typed with built in support for class invariants and in/out contracts you can't see the purpose of a TypeTuple?
 TypeTuple does not implement any functionality. It is an 
 'identity function'.

And yet the documentation: http://dlang.org/tuple.html (see Type Tuples) And the name clearly suggest that it DOES implement functionality - that of checking that the arguments are all types. On Monday, 27 May 2013 at 19:13:24 UTC, Andrej Mitrovic wrote:
 You are forgetting about performance. TypeTuple can be used *a 
 lot* in
 generic code. If you add static checking for each tuple element 
 you're
 going to slow down the compiler quite a bit. And you won't know 
 this
 if you only sporadically use TypeTuple.

Actually, given that all the template parameters are likely already being used (otherwise why have that parameter) the checking must already occur simply further down the line. In addition, I've run some tests using thousands of huge recursively defined tuples and I haven't been able to get any detectable different between using TypeTuple and StaticTuple. Unless someone can demonstrate some code which has a measurable difference in compilation time I think performance is not an argument.
 It's not undocumented behavior, it's documented, e.g. The D 
 Templates Book.

Fine, not documented on the official dlang site, or rather it's specifically documented that TypeTuples are only for storing types.
 Where do you get this clarity that it's only used for types? 
 Have you
 inspected all D libraries out there?

Of course not, my "clarity" comes from having gone through phobos and identifying which uses of TypeTuple would have to be changed to using StaticTuple. The only significant cases of it being used with non-types outside std.typetuple itself were in std.traits, which is hardly typical D code and is one file in a large library anyway. Hence my statement that most uses of TypeTuple were with types was based on the fact that it's true in phobos and therefore likely true in any sufficiently large code-base. Especially considering that significant contributers to phobos are more likely to know that using TypeTuple with non-types is allowed than the average user of D.
 It's not, because now you're forced to always compile with the
 deprecation switch.

As Jonathan said that's not true anymore. On Monday, 27 May 2013 at 19:30:18 UTC, Jonathan M Davis wrote:
 That being said, I don't really like the idea of deprecating 
 something with the intention that it stick around forever. It 
 just provides a smoother transition.

OK, let me amend my statement to "the transition can be as smooth as it needs to be".
 Yeah. The only problem I see is the name. I don't see any real 
 benefit in making it so that we have _three_ different types of 
 compile time tuples, particularly when their uses tend to be 
 fairly localized rather than being passed around through APIs 
 and the like (if they get passed through APIs, they'd just be 
 template or function argument lists), and any mismatch of types 
 and expressions will result in an error pretty much instantly.

Three? I am suggesting TWO, "StaticTuple" and "TypeTuple" with further additions for a future discussion. It gives good names to concepts we already have but have no way to refer to consistently. The term "TypeTuple" as used to mean a compile time tuple which contains types has a whole section in the documentation. Currently we don't have any way to talk about StaticTuples without being ambiguous and confusing. We can't use the term "TypeTuple" because that is already used as I've just described, and we can't use the term "Tuple" even though that is what's currently used in most places because a "Tuple" is something completely different in phobos! Using StaticTuple clearly and unambiguously refers to the alias to a "..." template argument. If a function's documentation says it accepts any StaticTuple then it's clear what that function expects. Likewise for TypeTuple. At the moment there's no way to determine whether a function can accept non-types without going through the phobos source code.
 So, holding both expressions and types isn't really a problem 
 IMHO - particularly since that's what the built-in tuples do, 
 and all TypeTuple really is is a template to let you create and 
 manipulate the built-in tuples.

I assume you are refering to what I am calling a StaticTuple rather than a Tuple in this case, because not so long ago I would have assumed that when you said "built-in tuple" you meant std.tuple.Tuple.
 So, if we change anything, we change the name via an alias and 
 leave all of the semantics alone. But given how much TypeTuple 
 is used and that the module is named std.typetuple, it would 
 likely have to be a permanent alias, in which case you _still_ 
 have to explain what TypeTuple is, and the gain of renaming it 
 is minimal IMHO (it could even make things _worse_ by 
 increasing the confusion by having multiple names).

TypeTuple is currently described in the documentation as a compile time tuple which contains types. This is still the case after introducing StaticTuple... The only difference is that now the description is actually correct.
 The name sucks, but I think that we're stuck with it at this 
 point. For it to be worth it, we'd have to be willing to force 
 everyone to change their code to use the new name, and for the 
 most part, we're just not doing that sort of thing anymore.

This makes no sense. All of the benefits of StaticTuple come without changing any existing code except for in phobos itself, in particular a logical naming system which actually matches the existing documentation.
May 27 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, May 28, 2013 00:23:08 Diggory wrote:
 On Monday, 27 May 2013 at 19:30:18 UTC, Jonathan M Davis wrote:
 Yeah. The only problem I see is the name. I don't see any real
 benefit in making it so that we have _three_ different types of
 compile time tuples, particularly when their uses tend to be
 fairly localized rather than being passed around through APIs
 and the like (if they get passed through APIs, they'd just be
 template or function argument lists), and any mismatch of types
 and expressions will result in an error pretty much instantly.

Three? I am suggesting TWO, "StaticTuple" and "TypeTuple" with further additions for a future discussion.

I thought that you were suggesting ExpressionTuple on top of the other two. Regardless, I see no reason to add yet more tuple types. Two is plenty. It's just that the name for TypeTuple sucks, because it's used for more than just types and arguably isn't a tuple to begin with (since it doesn't have nesting).
 Using StaticTuple clearly and unambiguously refers to the alias
 to a "..." template argument.

Right now, that's TypeTuple. The fact that Type is in the name means nothing other than the fact that it was poorly named. I'm quite certain that a number of the template-heavy projects out there use TypeTuple for expressions as well as types. I know that I have. You pretty much have to if you want to use expressions with static foreach.
 because not so long ago I would
 have assumed that when you said "built-in tuple" you meant
 std.tuple.Tuple.

std.typecons.Tuple isn't built-in. It's in the standard library. When I say built-in, I meant built into the language.
 The name sucks, but I think that we're stuck with it at this
 point. For it to be worth it, we'd have to be willing to force
 everyone to change their code to use the new name, and for the
 most part, we're just not doing that sort of thing anymore.

This makes no sense. All of the benefits of StaticTuple come without changing any existing code except for in phobos itself, in particular a logical naming system which actually matches the existing documentation.

If you introduce StaticTuple on top of TypeTuple, even without ExpressionTuple, you now have three different tuple types to explain, whereas now we only have two (which is already problematic enough). If you create an alias from TypeTuple to StaticTuple, then you only really have two tuple types, but you still have three of them in code, so you stil have to explain three of them. The documentation on TypeTuple is just plain wrong, and anyone who uses it much knows fulwell that it's wrong, so I consider it to be pretty much irrelevant. I think that the design of TypeTuple is perfectly sound - it's merely a way to create the tuples which are built into the language. It's just that a bad name was chosen. If we were willing to break code for name changes, I'd argue for changing it to something like StaticTuple, but Walter and Andrei are flat-out against that at this point. The ROI is too low for the amount of breakage that it causes - especially with something as heavily used as TypeTuple. If we were going to change the name, we should have changed it ages ago. I don't think that it's going to be acceptable to do so now, and I don't think that the confusion caused by adding an alias to it is an improvement. And I definitely don't think that trying to split out TypeTuple into a tuple that actually is a way to use the built-in tuple (like it is now) and one that only takes types is an improvement. So, I agree that the name sucks, and it would be great if we could change it, but at this point, I think that we're stuck, and we obviously need to fix the documentation to clarify it. - Jonathan M Davis
May 27 2013
prev sibling next sibling parent "Diggory" <diggsey googlemail.com> writes:
 Using StaticTuple clearly and unambiguously refers to the alias
 to a "..." template argument.

Right now, that's TypeTuple. The fact that Type is in the name means nothing other than the fact that it was poorly named. I'm quite certain that a number of the template-heavy projects out there use TypeTuple for expressions as well as types. I know that I have. You pretty much have to if you want to use expressions with static foreach.
 because not so long ago I would
 have assumed that when you said "built-in tuple" you meant
 std.tuple.Tuple.

std.typecons.Tuple isn't built-in. It's in the standard library. When I say built-in, I meant built into the language.

There's no point explaining it to me - I know what they are, and the only reason I know is because I've gone through and looked at the phobos code for both of them, something I shouldn't have to do.
 If you introduce StaticTuple on top of TypeTuple, even without
 ExpressionTuple, you now have three different tuple types to 
 explain, whereas
 now we only have two (which is already problematic enough). If 
 you create an
 alias from TypeTuple to StaticTuple, then you only really have 
 two tuple
 types, but you still have three of them in code, so you stil 
 have to explain
 three of them.

Sometimes explaining more things is better than explaining fewer things. Having recently gone through the process of learning about D tuples I can safely say that if instead "StaticTuple", "TypeTuple" and "Tuple" were explained it would have been much easier to understand. Are you really arguing that the existing system is easier to understand? A simple note that TypeTuple may be used in existing code to store non-types but that this usage is deprecated is enough to explain the entire situation to anyone, and even this is not necessary to remember unless you are specifically editing code written before StaticTuple.
 The documentation on TypeTuple is just plain wrong, and anyone 
 who uses it
 much knows fulwell that it's wrong, so I consider it to be 
 pretty much
 irrelevant.

How on earth is anyone supposed to know this if the documentation is wrong without going through the code. IMO the reason D has had such limited uptake despite all of its positive features has nothing to do with being too unstable, it's because every possible barrier is put up against novice programmers getting started with the language. A language grows in popularity because new people start using it, not because company X decides it's now crossed some imaginary stability threshold. There seems to be some illusion that being stable is about drawing a line and saying "from now on there will be no more code breakage". That's not being stable, that's not fixing problems with the language. A language is stable when sufficiently many of the problems that would require code changes have been fixed so that the remaining problems can be fixed without breaking code. The only possible outcome is either fixing the problems later which is worse because you break more code, or never being able to fix the problems satisfactorily (C++).
 I think that the design of TypeTuple is perfectly sound - it's
 merely a way to create the tuples which are built into the 
 language. It's just
 that a bad name was chosen. If we were willing to break code 
 for name changes,
 I'd argue for changing it to something like StaticTuple, but 
 Walter and Andrei
 are flat-out against that at this point. The ROI is too low for 
 the amount of
 breakage that it causes - especially with something as heavily 
 used as
 TypeTuple. If we were going to change the name, we should have 
 changed it ages
 ago.

What is the worst possible scenario if this change was implemented? Answer: some projects generate deprecation warnings until somebody can be bothered to press ctrl+H or *insert shortcut of your choice for replace all*. It won't actually break any code, so it's not a case of breaking code for name changes. The questions after the most recent dconf talk discussed an automatic conversion tool for upgrading code, and most of the people concerned with breaking changes were happy for those changes to occur if it was no effort for them to update the code. In this case I am not even suggesting breaking code, plus it's possible to upgrade the code using an automated tool that everyone already has. The benefits are significant. Maybe to someone who knows D inside out it doesn't matter but you have to cater to newcomers both now and in the future, not just existing users. If not, D will stagnate.
 I don't think that it's going to be acceptable to do so now, 
 and I don't
 think that the confusion caused by adding an alias to it is an 
 improvement.

IMO, StaticTuple + TypeTuple + Good documentation is less confusing than TypeTuple + Good documentation. Plus the former reflects better on the language. Seeing the former and reading about TypeTuple I would think D is a language where the problems have been fixed (without code breakage). Seeing the latter I would think D is a language where things that are broken will never be fixed. In the former the bit that needs some more explanation is the exception to the rule (TypeTuple with non-types). In the latter the bit that needs some more explanation is the rule itself (TypeTuple is not actually a TypeTuple).
 And I definitely don't think that trying to split out TypeTuple 
 into a tuple
 that actually is a way to use the built-in tuple (like it is 
 now) and one that
 only takes types is an improvement.

Given that there is special treatment in the compiler for when all the parameters are types it seems absurd not to have a name for tuples which meet the criteria.
May 27 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, May 28, 2013 04:52:50 Diggory wrote:
 Are you really arguing that the existing system is easier to
 understand?

I'm arguing that the only problem in the current design is the name. TypeTuple is a template for creating built-in tuples, and the built-in tuples deal with both expressions and types, so that's what TypeTuple should do. The fact that it's called TypeTuple is a problem, because it doesn't just deal with types, and the fact that the documentation indicates that it just deals with types is a problem, because it doesn't. But I don't think that there's any problem with how the template itself works. If I could go back, I'd rename TypeTuple to something like StaticTuple, or ParamTuple, or ArgTuple, or ParamSeq, or ArgSeq, or some other name which made more sense for what it does. But given that we can't go back in time, we have to contend with the fact that both the module and template have the name TypeTuple (albeit with different capitalization) and that changing them would break a lot of code. And Walter in particular is very much against making breaking changes which don't have a large ROI, and he and Andrei have made it clear that they don't want to be changing symbol names in the library at this point just because the names aren't as good as they should be. The ROI is too small. So, at this point, the fact that a name is poor is generally _not_ enough to get it changed. TypeTuple is bad enough that they _might_ agree to it, but I doubt it. So, given the current situation, we clearly need to improve the documentation, but that's probably all that we can do. Regardless, I have _zero_ problem with the design of TypeTuple, just the name. - Jonathan M Davis
May 27 2013
prev sibling parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
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
May 28 2013