TypeInfo in the library

[Mike via Digitalmars-d]

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:

I'm thinking about trying to implementing this.  There's some 
promising work in GDC[1] and DMD[2] related to reigning in 
TypeInfo, but it comes with compromises (e.g. not being able to 
use some of the convenient array-related functions and postblit).

[1] (GDC -fno-typeinfo) - 
https://github.com/D-Programming-GDC/GDC/pull/100
[2] (DMD Resolve TypeInfo variables after semantic) - 
https://github.com/D-Programming-Language/dmd/pull/4654

However, that work has helped me better understand what the 
compiler's doing and, with a little more study, I might be able 
to tackle this implementation.

> 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'm wondering if (2) and (3) need happen to keep the status quo.  
typeid(T) would need to return TypeInfoImpl!(T), but if 
TypeInfoImpl!(T) is absent from the runtime, we could just throw 
a compiler error.  Currently if no TypeInfo is implemented in the 
runtime, errors happen, so we'd be no worse off.

For (3), is the trait really needed to keep the status quo? 
Again, the compiler would just throw an error if 
TypeInfoImpl!T.init() is not found.

As a result, the runtime would still need to have a 
TypeInfoImpl!(T) to get a build, but at least only what's 
actually used would need to be implemented.

Am I missing something?

Also, I think it solve the TypeInfo code bloat problem [3] when 
compiling with -ffunction-sections/-fdata-sections/--gc-sections. 
  The reason being that the compiler would no longer be "packing" 
the TypeInfo as alluded to in [4].

[3] (TypeInfo.name strings don't get put into separate sections 
when compiling with -fdata-sections) - 
http://bugzilla.gdcproject.org/show_bug.cgi?id=184
[4] (TypeInfo Packing) - 
http://forum.dlang.org/post/lfyehafdfrrktbwqemhu@forum.dlang.org

Mike