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.
