BetterC and TypeInfo Question

[Mike via Digitalmars-d-learn]

On Friday, 23 June 2017 at 02:14:08 UTC, Adam D. Ruppe wrote:

> Yes, it is necessary, but how much? Can we do it with 
> implicitly generated library code?
>
> I'm pretty sure the answer is "not much" and "yes", but I still 
> need to ponder the details. I think the typeinfo for a class 
> good enough for dynamic cast could be about half the size we 
> have now.
>
> Though like I said, a lot of the stuff we have now is cool 
> stuff, so I don't want to miss it entirely, it could be behind 
> another pointer.

I'm not sure what you have in mind, but TypeInfo in itself is not 
bad and has some very useful features even for resource 
constrained devices and other niche domains.

The problem is that the current compiler-runtime requires it to 
exist just to get a build, even though it's not being used in the 
source code (implicitly or otherwise) and has no chance of ever 
being executed or referenced in the resulting binary.

Also, TypeInfo has been overused in the compiler-runtime 
implementation.  For example:  
http://forum.dlang.org/post/mrmv61$230i$1@digitalmars.com

The compiler should be able to generate the object code in a way 
that allows the linker to discard it, if it can't find anything 
that uses it.  I think LTO has made such features even more 
intelligent.

I'd like to see 3 improvements:
1.  The compiler doesn't require TypeInfo to be implemented in 
the runtime if the user's code will never make use of it.
2.  If TypeInfo is implemented in the runtime, the compiler 
generates the object code in a way that permits the linker to 
discard it if it can't find a link to it.
3.  If only one item is needed out of TypeInfo, pass a reference 
to that instead of the entire TypeInfo object in the 
compiler-runtime implementation, so implementations can be made 
more granular.  Or perhaps TypeInfo should be broken up into a 
few smaller types.

Mike