• Denis Shelomovskij (41/41) Nov 25 2012 Currently there is a lack of meta features in D standard library.
• Jacob Carlborg (5/7) Nov 25 2012 I can't see any problem in creating a package for this. I would though
• David Nadlinger (41/51) Nov 26 2012 I find this statement somewhat funny: Instantiate is only two

Denis Shelomovskij <verylonglogin.reg gmail.com> writes:

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

Jacob Carlborg <doob me.com> writes:

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

"David Nadlinger" <see klickverbot.at> writes:

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 

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