Discussion of TypeTuple naming

[Timon Gehr]

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.