std.reflection prototype

Kapps via Digitalmars-d digitalmars-d at
Sun Mar 29 22:26:10 PDT 2015

On Monday, 30 March 2015 at 05:06:14 UTC, bitwise wrote:
>> This definitely should be a library solution.
> In terms of what Andre was suggesting, I think my 
> implementation is 90% of the way there, so if the will was 
> there to add something like std.reflection to phobos, it 
> wouldn't be much of a leap.
>> But it seems silly, to not use code in druntime.
> I kind of agree. If I had things my way, all reflection info 
> for all classes would be compiler generated so that it was 
> guaranteed to be there for tools, interop and such. If people 
> were really worried about code bloat, the reflection info could 
> simply be turned off with a -no-reflection flag or something.
> In terms of playing around with the compiler and the type 
> system, I'm not sure how helpful I could be right now. I'm 
> pretty sure comprehension will not be a problem, but I've got 
> quite a bit of reading to do before I'm up to speed with whats 
> going on with dmd and the type system.

When I tried mine 
which was admittedly a while back, the template bloat was 
actually a significant problem. On Linux and OSX, the build for 
just the unittest library would generate an over 40MB executable. 
On Windows with Optlink though, it was only 4MB, so perhaps there 
are optimizations that could be made to reduce the size on OSX / 
Linux. Either way though, that's way too much bloat for something 
in druntime, and I don't think it's necessary. While it might be 
nice to use RTInfo to generate reflection data for your whole 
program, most people would be perfectly okay with at most a few 
modules, possibly recursively. Also, from what I can tell you 
generate a class for every symbol. This could generate a 
significant amount of bloat as well because it would generate 
further TypeInfo for each of these classes. I could be wrong 
here, but if that's the case, perhaps changing to structs would 
be a better choice if possible?

More information about the Digitalmars-d mailing list