TypeInfo in the library

Adam D. Ruppe destructionator at gmail.com
Thu Feb 13 16:42:07 PST 2014


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 :)


More information about the Digitalmars-d mailing list