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
