Shouldn't __traits return Tuples?

[Max Samukha]

On Mon, 30 Mar 2009 15:06:09 +0200, Trass3r <mrmocool at gmx.de> wrote:

>Shouldn't __traits return Tuples instead of arrays (esp. allMembers) to 
>allow sophisticated compile time reflection?
>Currently it seems impossible to do something along the lines of
>
>foreach (member; __traits (allMembers, Class))
>{
>     foreach (overload; __traits (getVirtualFunctions, Class, member))
>     {
>         // do stuff
>     }
>}

It's possible to statically unroll the foreach's with a template
generating a tuple of consequtive integers (not tested):

template Sequence(size_t count, size_t index = 0)
{
   static if (index < count)
      alias Tuple!(index, Sequence!(count, index + 1)) Sequence;  
   ...
}

enum members = __traits (allMembers, Class);
foreach (i; Sequence!(members.length))
{
     enum funcs = __traits (getVirtualFunctions, Class, members[i]);
     foreach (j; Sequence!(funcs.length))
     {
         // do stuff
     }
}

I'm not sure __traits should return tuples because arrays can be used
with CTFE without generating an extra symbol, meaning less code bloat.

>
>Maybe it would be possible with Tuples using template recursion.
>
>
>
>Also the following doesn't work with dmd, returns 0 for all members:
>
>Base base = new Base;
>auto members = __traits(allMembers, typeof(base));
>foreach(m; members)
>     writefln(base.classinfo.getMembers(m).length);

getMembers has not been implemented, AFAIK