Proposal for __traits

[Bill Baxter]

Robert Fraser wrote:
> Leonard Dahlmann Wrote:
> 
>> That's basically a nice idea. The problem with that though is, that
>> the properties would need to be available at both compile time
>> and runtime. IMO, RTTI is bloated enough like it is now.
> 
> How different our viewpoints are... I've been campaigning for runtime
> reflection for a while now, and you're against it :-).

I'm opposed to a mandatory, global fully dynamic runtime reflection 
mechanism because I believe it will lead to tremendous bloat in exe 
sizes (c.f. Stroustrup's example where adding reflection to some app led 
to 16x increase in memory usage).  If it can be shown that the *bloat* 
in runtime resource usage won't happen, then I'd be in favor.

Otherwise I think compile-time only makes sense.  That way, only the 
things you actually use have to be included by the compiler.  While it 
might be nice to be able to say:
     char[] cat = read_category_from_user();
     char[] classname = read_class_name_from_user();
     auto a = __traits(cat, classname);
that would mean that all possible reflection info for all types must be 
kept in the exe.

With a compile-time mechansim you can selectively make the info you want 
available at runtime, but it's not mandatory.

class D
{
     this() { }
     ~this() { }
     void foo() { }
     int foo(int) { return 0; }
     static char[][] allMembers() {
         return __traits(allMembers, typeof(this));
     }
}

Voila! Now the allMembers info is available at runtime[1] for class D, 
And the compiler is free to leave out all the rest of the reflection 
info that you weren't planning on using anyway.  And you can of course 
easily stick that and other functions in a template to use as a mixin. 
  Everybody wins[2].

--bb
[1] the above code probably won't work due to lack of const and whatnot, 
but you get the idea.

[2] Except people who want to do arbitrary runtime reflection on unknown 
code loaded from a dll at the expense of lots of memory bloat.