std.typelist

[David Nadlinger]

Wow, I never noticed that this file exists, even though I'm 
routinely doing metaprogramming-heavy stuff…

The obligatory references to other »meta« code:
[1] 
https://github.com/sinfu/phobos-sandbox/blob/master/std/internal/meta/meta.d
[2] 
https://github.com/PhilippeSigaud/dranges/blob/master/templates.d
[3] https://gist.github.com/1191885 (this was a one-off selection 
of my own code for a NG discussion, feel free to ask for more/an 
updated version)

On Friday, 22 June 2012 at 18:10:38 UTC, Alex Rønne Petersen 
wrote:
> On 22-06-2012 20:06, Jonathan M Davis wrote:
>> The question is what to do with it. […]
> Yeah, I really think we need to ship this stuff.

I'd rather not ship it without more consideration and a proper 
review process. Yes, functionality supporting more advanced 
manipulation of compile time lists/tuples is definitely needed 
(cf. the countless std.meta discussions), but:

  1) The term TypeList does not make much sense at all, as compile 
time tuples/lists aren't at all restricted to types. In 
retrospect, giving TypeTuples the name they bear was a mistake, 
we shouldn't repeat it. The genreral template would become 
meta.List (no, I never got around to finishing my proposal), and 
a meta.TypeList constructor could then ensure that only types are 
accepted (similar for meta.ExprList, or whatever good names there 
might be).

  2)  I'm not sure if introducing a concept which is essentially 
the same as TypeTuple, but doesn't entirely replace it for 
»high-level« use, is the right way to go. Yes, functional-style 
head/tail lists are a natural fit for many meta-algorithms, since 
the semantics of templates mostly require a very functional style 
anyway (you'll frequently see T[0] and T[1 .. $] in type 
tuples-heavy code). And yes, the »auto-expanding« property of 
TypeTuples can sometimes lead to unexpected results, and for some 
»higher-order« templates, you need to confine them into another 
template (imagine TypeList with only toTuple, see [1], [3]).

But on the other hand, type tuples are deeply anchored in the 
language (variadics, ...), and better match the general 
array/range theme of D, thus probably reducing »mental 
overhead« for people not used to functional programming.

This is not to say that I don't find the std.typelist concept 
interesting. We just should be very clear on how to go forward 
with »meta« algorithms in Phobos before going forward with 
this. Developing std.typelist and std.typetuple side by side, and 
then at some later point also introducing std.meta doesn't make 
much sense, in my eyes.

  3) I think going for an explicit »apply« method for template 
predicate is not worth the hassle in the general case (in user 
code, which usually just passes predicates to higher order 
templates). Instead, I prefer using an explicit Apply/Instantiate 
template where needed to overcome grammar limitations, which 
mostly is in the implementation of the primitives.

  4) I know this is picking nits at this stage, but I think And/Or 
should implement short-cut evaluation, like in [3].

One more thing I noticed is that the module doc comment solely 
lists Bartosz as the author, but the file has another copyright 
comment mentioning Burton Radons. This situation should 
definitely be clarified.

David