Re: Fields with the same name not causing a warning?

[Basile B. via Digitalmars-d-learn]

On Friday, 16 November 2018 at 15:59:14 UTC, Vinay Sajip wrote:
This code should IMO give at least a warning, but it doesn't:
abstract class A {
    int kind;
}

class B : A {
    int kind;

    this(int k) {
        kind = k;
    }
}

In my actual code, the declaration of field "kind" in B was 
left in accidentally. Surprisingly, however, no warning was 
emitted when I compiled this, leading to B having two fields 
called kind which are distinct from one another. The complete 
program

import std.stdio;

abstract class A {
    int kind;
}

class B : A {
    int kind;

    this(int k) {
        kind = k;
    }
}

void main()
{
    auto b = new B(4);
    A a = b;

    writeln(b.kind);
    writeln(a.kind);
}

prints

4
0

Given that this is the kind of thing that is easily done, 
surely the default behaviour should be for the compiler to emit 
at least a warning that field "kind" is ambiguous in B? This 
behaviour occurs even when the field is declared as "public" or 
"protected" in both classes. What am I missing?

When you re declare with the same name in a sub class each 
generation has its own variable. To distinguish you can use the 
type for which you want "kind":

    writeln(b.A.kind); // the one from A
    writeln(b.B.kind); // the one from B

I agree that this is almost a case of shadowing but i don't know 
the exact rationale for allowing this.