Adam D Ruppe's proposal originally posted here: http://forum.dlang.org/post/[email protected]
*****************************************
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 :)
Comment #1 by andrei — 2020-09-25T15:13:24Z
This is important for allowing compile-time manipulation of TypeInfo objects. I changed importance to P5, not sure whether that does anything :o).
Comment #2 by robert.schadek — 2024-12-13T18:17:33Z