Automatic removal of RTTI (as well as automatic removal if method virtuality) could have very unpleasant effects in modular architectures. Consider this use case:
// Base.dll class Base { string method() { return "Base"; } } // Derived.dll class Derived: Base { string method() { return "Derived"; } } Base baseFactory() { return new Drived; } // Main.exe export Base createBase void main() { Base b = baseFactory(); writeln(b.method()); } When compiling Base.dll, the compiler doesn't see any class deriving from it, so it can remove the method from vtbl, In that case a Base. returned from Base.dll would be a completely different class, then a Base, returned from Derived.dll, since their vtbl would differ. This would lead to major problems with functions, expecting a certain ABI, but getting a different ABI. This is an unnecessary inconsistency. marking methods as final is purely optimization technique in this case and performance should never cost consistency. The compiler could emit recommendations about potentially inconsistent optimizations. On Fri, Oct 21, 2011 at 11:35 AM, Marco Leise <marco.le...@gmx.de> wrote: > Am 21.10.2011, 09:20 Uhr, schrieb Gor Gyolchanyan > <gor.f.gyolchan...@gmail.com>: > >> Actually, the best idea would be to enable full reflection (much more >> complete, then what we have now) by default and allow to remove it on >> demand. >> Just like the methods being virtual by default, but with ability to >> make them final. > > As far as I know that is just what the programmer sees. If the compiler can > verify that the method doesn't need to be virtual it will make it static by > default. In terms of RTTI it would resemble to "add RTTI to a type only when > we cannot be sure it isn't needed". >