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
[email protected]
http://lycus.org
