TypeInfo in the library

[Rainer Schuetze]

On 14.02.2014 01:42, 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 like this idea (I remember I had this also as a suggestion on my 
slides for dconf2013). This is just taking the RTInfo template 
generation a step further, yet coming with the same problems. See this 
pull request for a (probably incomplete) list of places I found where 
type info generation is triggered from the glue code, and not during 
semantic analysis:

https://github.com/D-Programming-Language/dmd/pull/2480

The only drawback I see is that it makes compilation a bit slower and 
pollutes object files with code just executed during CTFE. Unfortunately 
this often also ends up in the executable because it is referenced by 
some data not in COMDATs.