Why is this allowed? Inheritance variable shadowing

[Chris Katko]

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