Discussion of TypeTuple naming

[Andrej Mitrovic]

On 5/27/13, Diggory <diggsey at 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.