Proposal for __traits

[Robert Fraser]

How about some kind of modifier that can be applied to a type to export additional RTTI?

Bill Baxter Wrote:

> 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.