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
