Currently there is a lack of meta features in D standard library.
So the following modules are proposed for inclusion in Phobos.

http://denis-sh.github.com/phobos-additions/unstd.templates.html

    Major features:
* 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.
* create template from string
* bind template arguments
* combine template predicates
    NOTE: partially already in Phobos's std.typetuple but with worse (IMHO) names and with at least incorrect `notTemplate` analogue.


http://denis-sh.github.com/phobos-additions/unstd.generictuple.html

    Major features:
* generic tuple general templates
    There should be at least both GenericTuple and TypeTuple as the latter is a common use case of generic tuples. E.g. TypeTuple is used ~70% of generic tuple usage in Phobos.
* packed generic tuple templates
    Useful when passing more than one generic tuple to a template.
* generic tuple creation templates
    Templates for generic tuple creation by analogy with range creation functions from std.range.
* generic tuple algorithm templates
    Templates for various algorithms on generic tuples by analogy with range algorithm functions from std.algorithm.

IMHO, it will be very convenient to make generic tuple processing functions by analogy with range processing as it will allow user to learn only one functions set for both runtime and template programming.


Also I don't like the current situation with infinite `std` package grow and would like to use `std.meta` or just `meta` for these modules.


See also:
* http://denis-sh.github.com/phobos-additions/
the full list of [potential] Phobos proposals
* http://d.puremagic.com/issues/show_bug.cgi?id=3702
Issue 3702 - Replace __traits and is(typeof()) with a 'magic namespace'

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

On 2012-11-26 07:16, Denis Shelomovskij wrote:

> Also I don't like the current situation with infinite `std` package grow
> and would like to use `std.meta` or just `meta` for these modules.

I can't see any problem in creating a package for this. I would though put it in the std root package, i.e. std.meta.generictuple and so on.

-- 
/Jacob Carlborg

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