Proposal for __traits

[Bill Baxter]

davidl wrote:
> __traits itself is great
> though i think adding some builtin properties for class would be nicer
> 
> consider
> 
> class D
> {
>     this() { }
>     ~this() { }
>     void foo() { }
>     int foo(int) { return 0; }
> }
> 
> D.members[] -> 
> "_ctor","_dtor","foo","print","toString","toHash","opCmp","opEquals"
> 
> 
> myclass.allmembers[] -> "i","j"
> 
> class D
> {
>     this() { }
>     ~this() { }
>     void foo() { }
>     int foo(int) { return 0; }
> }
> 
> D.allmembers.derived[] -> "_ctor","_dtor","foo"
> 
> class D
> {
>     this() { }
>     ~this() { }
>     void foo() { }
>     int foo(int) { return 2; }
> }
> 
> D.allmembers.VirtualFunctions[] -> ["foo":void delegate (),"foo":int 
> delegate(int)]
> 
> getVirtualFunctions could be something developed by meta programming
> 
> struct S
> {
>     int mx;
>     static int my;
> }
> 
> S.members["mx"] = 3;        // this looks nicer, but we need to extend 
> our type struct of members, typeof for members is a bit strange
> 
> also final functions , abstract functions could be some sub properties

That would steal a lot of possible member names from structs/classes and 
would mean you couldn't introduce new traits without potentially 
clashing with symbols in people's code.

How about using D.traits.<element> or D.__traits.<element> instead?  But 
once you do that it's really just a small cosmetic difference between 
that and __traits(D,<element>).

--bb