DIP54 : revamp of Phobos tuple types

[Jakob Ovrum]

On Tuesday, 24 December 2013 at 04:08:25 UTC, H. S. Teoh wrote:

> So if we only implemented the first part of the DIP, the 
> renaming of
> std.typeconds.TypeTuple -> std.meta.list (or whatever, let's 
> not start
> bikeshedding this early), along with the documentation cleanup 
> which is
> long overdue anyway, would that be more acceptable to you?

Yes, that's exactly what I've been arguing for since forever!

> Which requires users to reinvent their own
> wrappers, which defeats the purpose of standardization.

We should have both[1], with the auto-expanding one being the 
most commonly required.

> Is it really *that* common to want your lists
> auto-expanded by default?

Yes, it is. It's a natural consequence of how the language 
feature works.

At the end of the line, after being passed around to other 
templates for processing (discussed below), use of template 
argument lists boil down to several scenarios:

* Use for declaring an expression list from a type list, e.g. in 
a function parameter list or for fields in an aggregate. Requires 
expansion.

* Use for initalizing other expressions lists with an expression 
list, e.g. passing an expression list as arguments in a function 
call or in an array literal. Requires expansion.

* Use in static foreach. Requires expansion.

* Use in special expressions that operate on types, such as `is`, 
`typeof` and `typeid`. Requires expansion.

* Use as a public alias in a library interface, leaving the 
specifics of application to the user (but it always boils down to 
the above scenarios). Equal for both behaviours.

(Some but not all of the above might be equalized by Timon Gehr's 
AliasThis suggestion, but this remains to be proven)

Further, there is the issue of the processing itself - passing 
lists to algorithms receiving lists. If all of Phobos' list 
algorithms are rewritten to expect non-expanding lists, usage 
remains the same, for the *extremely* niche benefit of supporting 
a specific kind of variadic algorithm with the same kind of list. 
That's a whole lot of work for a whole lot of nothing.

Hence, I think this DIP is nothing but absurd. Excuse the strong 
language but I'm upset that it has caused a delay in the overdue 
renaming issue.

[1] Assuming that the case for non-auto-expanding lists can be 
argued sufficiently for inclusion in Phobos, which is yet to be 
seen. This DIP doesn't seem to even try.

P.S. I too like the name `list` to replace the current 
`TypeTuple`. The capitalization is correct with the new Phobos 
rules for list algorithms, and the succinctness respects how 
commonly used the template is.