You can drop this straight into run.dlang.io:
import std.stdio;
class base{ float x=1;}
class child : base {float x=2;} //shadows base variable!
void main()
{
base []array;
child c = new child;
array ~= c;
writeln(c.x); //=2
writeln(array[0].x); //=1 //uses BASE's interface, yes,
//but why does the CHILD instance one exist at all?
}
It appears to be legal C++ as well but I can't imagine a
situation where you'd want to allow the HUGE risk of
shadowing/aliasing variables in an child class. Why is
inheritance shadowing allowed? Especially when in D you have to
explicitly "override" existing _methods_ but not fields/variables?
To quote a Stack Overflow comment on C++ having this "It's not a
compile error, but it's certainly a design one." Is this allowed
just because "C++ does it" or because it has some sort of real
world use that justifies the risk?
Personally, I'd love a compile-time warning that I could turn on
that flags this situation.
Thanks for your help,
--Chris
