forbid field name conflict in class hierarchy

[Stanislav Blinov]

spir wrote:
> Hello,
> 
> 
> I think the compiler should complain when sub-classes hold fields with the same name as super-classes. After all, names (in addition to types) are used to identify. Intentionally reusing the same name would not only be bad design, but open the door to hidden bugs.
> Remain unintentional name crash: eg forgot to remove a field when established type hierarchy. Allowing same names lead to strange contradictions by the language -- see below. Without such a rigor imposed the compiler, we can easily fall into traps such as:
> 
> class C {
>     int i;
>     this (int i) {
>         this.i = i;
>     }
> }
> class C1 : C {
>     // forgot to remove i
>     int i;
>     int j;
>     this (int i, int j) {
>         super(i);	// think i is set?
>         this.j = j;
>     }
> }
> void main () {
>     auto c1 = new C1(1,2);
>     writeln(c1.i);  // 0
> }
> 
> Got me 3 times already. I don't understand how it is even possible that C.i is not the same as C1.i, but evidence is here... There is a contradiction: i is set && not set. (explaination welcome ;-)
> 
> Denis
> -- -- -- -- -- -- --
> vit esse estrany ☣
> 
> spir.wikidot.com
> 

This issue has been brought up several times before. I myself see no 
harm in this shadowing, though making a compiler issue a warning
when shadowing *public* fields occurs would be a good thing.
Shadowing non-public fields, in my opinion, is harmless, and preventing 
it would actually narrow down name choice with each subsequent subclassing.

The other option that comes to mind is simply disallow public fields for 
classes. This may sound too strict, but I think that public fields is 
something that's not as usable for classes as for structs.