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