[RFC] Modules for template programming proposal

[David Nadlinger]

On Monday, 26 November 2012 at 06:16:43 UTC, Denis Shelomovskij 
wrote:
> * instantiate template
>    A convenience util to instantiate templates needed because 
> of D
>syntax issues.
>   NOTE: already in Phobos but with inexcusable long name for 
> such
>common used D syntax issue workaround.

I find this statement somewhat funny: Instantiate is only two 
characters longer than TypeTuple, which is probably _really_ 
commonly used. Instantiate, on the other hand, tends to be used 
only in library code in my experience, and only when 
writing/testing a very specific sort of templates – probably 
comparable in frequency to MultidimensionalStaticArrayElementType.

I specifically chose the longer name to make error messages 
involving it obvious to users, in case that some template blows 
up (I think I used "Inst" or "Apply" originally before 
publication).

As Instantiate is currently private (and utterly trivial, by the 
way), this can be changed at any point without problems, though.


>     NOTE: partially already in Phobos's std.typetuple but with 
> worse (IMHO) names

I'm not particularly fond with the names we ended up in 
std.typetuple with either; I would have just gone with Not, Any 
and All (uppercase as their results are templates, not values). 
Andrei argued for lowercase, and that's how we ended up with 
templateXyz (staticXyz would just look horrible).

I don't really like your naming scheme either, though: 
notTemplate!(T) reads like »is T not a template« to me.


> and with at least incorrect `notTemplate` analogue.

The implementation of templateNot is _not_ incorrect, to the best 
of my knowledge it works exactly as intended.

Somewhat puzzled about what you meant by this, I looked at your 
example: What you are trying to do there is template composition, 
which simply doesn't work like that, just as it wouldn't for any 
other template either (if you had phrased your comment in #690 in 
a less patronizing way, you probably would have gotten an answer 
from someone back then).

I don't think it is a good idea to special-case templateNot in 
that regard; it's just extra conceptual complexity. Instead, why 
not properly use template composition? For a generic 
implementation of this, see: https://gist.github.com/1191885 
(Boost-licensed). Using it, your code would become »alias 
Compose!(templateNot, templateNot) toBoolTemplate;«.

The main reason why I have not proposed these for Phobos yet is 
that there is no consensus on how to move forward with these 
kinds of metaprogramming helpers in std. Somewhat unfortunately, 
templateAnd/Or/Not are now in std.typetuple, as Jonathan pushed 
for them, but this certainly isn't a solution for the long term.

David