On Sunday, 2 June 2013 at 09:33:27 UTC, Benjamin Thaut wrote:
I think this is a very good idea. The only question is how complete this RTTI should be.
For now, I'm going for just a UDA based thing, so it is almost all opt-in. Though one downside of my idea here is it may be slow, since it pulls info from a list (I'm doing a linear array, but it could be a binary search of AA or something without much difficulty, but my guess is most entries will only be a handful of elements long anyway).
Actually adding members to the rtinfo struct would avoid this cost, but I can't think of any way to do that without modifying object.d for each one.
Perhaps we could have a userRtInfo template that works the same way, but that one is defined in the module that defines the type, instead of in object.d. The module would be responsible for casting the void* in typeinfo (a new method, urtInfo to complement rtInfo) back to the type they defined. I think that would be doable at least.
The other thing I'm pondering is changing TypeInfo to be generated at compile time and include all kinds of functions like std.traits offers. This would only be builtin types, user structs and classes have RTInfo instead, so that limits the size somewhat, but it nevertheless does increase exe size and isn't easy to opt out of, since you'd have to recompile at least part of druntime to do it.
Expanding typeinfo is arguably less useful since if you want that info, you can do it yourself in a template like std.variant, but one use I can see is the D style variadics. Instead of a list of types with code right there, you could just do typeid().is/getNumeric() or whatever.
The RTInfo template is very usefull for many different tasks, the question is if we shouldn't make the concept more generic so that you can have multiple templates which behave like the RTInfo template. I'm currently also using it for RTTI info see: http://3d.benjamin-thaut.de/?p=25
very cool.
