www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [RFC] Modules for template programming proposal

reply 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
Nov 25 2012
next sibling parent 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
Nov 25 2012
prev sibling parent "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 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
Nov 26 2012