std.typelist

Alex Rønne Petersen alex at lycus.org
Fri Jun 22 12:25:48 PDT 2012


On 22-06-2012 21:13, 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.
>
> David

Well, author is not necessarily the same as copyright holder. Author 
usually means "maintainer" or "previous maintainer", while copyright 
could simply indicate that some code was borrowed.

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org




More information about the Digitalmars-d mailing list