TypeInfo in the library

Mike none at none.com
Wed Feb 26 17:09:09 PST 2014


On Friday, 14 February 2014 at 00:42:08 UTC, Adam D. Ruppe wrote:
> I'd like to see typeinfo moved completely to the library. The 
> language would then not depend on it directly. The point of 
> this thread is to see how practical it is. Here's the changes I 
> have in mind:
>
> 1) Stop automatic generation of TypeInfo.
>
> 2) typeid(T) in the language now returns a static instance of 
> TypeInfoImpl!T. The vtbl entry in a class also points to this. 
> If the library doesn't implement TypeInfoImpl(T), these return 
> null.
>
> 3) Add __traits(classInitializer, Class) which returns what we 
> have today through typeid(Class).init. (This would be used to 
> make init in the library implementation)
>
>
> I think the others are already possible:
>
> string TypeInfoImpl!T.toString() { return T.stringof; }
> interface TypeInfo {} /* TypeInfoImpl(T) : TypeInfo */
>
> // ElementType used for illustration only, no need to depend on 
> phobos since we can do this with an is expression too. that's 
> just harder to read/write lol
>
> TypeInfo TypeInfoImpl!T.next() { return typeid(ElementType!T); }
>
> Interfaces and parent class can also be done with traits today, 
> so we can auto-generate the with a template too.
>
>
> And so on, look at druntime's typeinfos now, most of it is just 
> doing a bunch of casts of the same code - easily templated.
>
>
>
> If I'm not missing anything, these three changes would let us 
> completely define (or not define) type info in the library 
> without breaking anything we have now!
>
>
> Functions that depend on typeinfo can be generated the same way 
> as they are now, though of course, I'd also enjoy moving more 
> of those things (arrays, etc.) to be templates too :)

Added enhancement bugzilla because it's a great idea: 
https://d.puremagic.com/issues/show_bug.cgi?id=12270


More information about the Digitalmars-d mailing list