[phobos] More tuple algorithms with std.meta

[Philippe Sigaud]

On Tue, Sep 28, 2010 at 16:52, Robert Jacques <sandford at jhu.edu> wrote:
>
> On Tue, 28 Sep 2010 06:10:56 -0400, Shin Fujishiro <rsinfu at gmail.com> wrote:
>
>> "Robert Jacques" <sandford at jhu.edu> wrote:
>>>
>>> The meta namespace has been proposed as a possible replacement for
>>> __traits, etc. i.e. meta.compiles() vs __traits(compiles, ). So a
>>> different module name might be appropriate.
>>
>> I'll consider.  BTW, will this really happen, or rather is it necessary?
>> IIRC, the proposal was against the ugly syntax.  I think all the
>> existing __traits except compiles could be wrapped with library
>> templates with syntactic sanity and added flexibility.  For example:
>>
>>
>> template getMember(alias Scope, string member)
>> {
>>    alias Identity!(__traits(getMember, Scope, member)) getMember;
>> }
>>
>> // This overload does partial application.  Useful for staticMap etc.
>> template getMember(alias Scope)
>> {
>>    template getMember(string member)
>>    {
>>        alias .getMember!(Scope, member) getMember;
>>    }
>> }

Looking at it, most traits seems wrappable in this way, except 'compiles'.

[meta]
> I don't know if this is on the road map or not, I just remember a decently serious discussion about it. I do like your solution, although some __traits would require tuples of aliases and for aliases to support types in addition to expressions. Since we'd hopefully be able to do both some time in the future, no reason not to start a limited form of it now. Also, since things like getMember are fairly generic for the public namespace, they should probably be put into a holding struct (e.g. meta). This could also apply to your staticMap, staticReduce, etc. (i.e. meta.map and meta.reduce). This has the advantage of using with(meta){ } when large blocks of metaprogramming are written.


And I find it easier on the eye to see meta.filter than staticFilter
(even though I'm using the latter in my code).


Philippe



std.compiletime?