std.typelist

Jonathan M Davis jmdavisProg at gmx.com
Fri Jun 22 14:00:17 PDT 2012


On Friday, June 22, 2012 21:13:07 David Nadlinger wrote:
> 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.

I tend to agree with all of this. I think that std.typelist looks very cool, 
but we need to make sure that it fits in well with what we want to do. Simply 
adding it to the makefiles and documentation without much in the way of 
discussion is probably a bad idea. I suppose that the real question is where 
we want to go with this and who's going to spearhead sorting out the fancier 
metadata stuff - particularly since std.typelist is a lot more of a shift than 
simply adding a trait or two to std.traits.

- Jonathan M Davis


More information about the Digitalmars-d mailing list