typeof()

[Gor Gyolchanyan]

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.Leise at gmx.de> wrote:
> Am 21.10.2011, 09:20 Uhr, schrieb Gor Gyolchanyan
> <gor.f.gyolchanyan at 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".
>