Another, is it a bug?

[Meta via Digitalmars-d-learn]

On Wednesday, 16 September 2015 at 02:59:06 UTC, Random D user 
wrote:
> I'm trying to make a base class with get property and a sub 
> class with corresponding set property. The value for the base 
> class is set via constructor.
> The intuitive way doesn't seem to work and workarounds are 
> unnecessarily ugly (considering you'll sprinkle them all over 
> the codebase).
>
> class Father
> {
>     int eat()
>     {
>         return 1;
>     }
> }
>
> class Daughter : Father
> {
>
>     void eat( int apples ) {}
>
>     // int eat() { return super.eat(); }    // Workaround A, 
> works as expected
>     //override int eat( int apples ) {}     // Workaround D, 
> fails -> Error: function main.Daughter.eat does not override 
> any function, did you mean to override 'main.Father.eat'?
> }
>
> Daughter d = new Daughter();
>
> // BUG? I expected this to work. It seems that compiler doesn't 
> even look into parent class to see if there's a matching 
> function.
> //int num = d.eat();                // Error: function 
> main.Daughter.eat (int apples) is not callable using argument 
> types ()
>
> int num2 = (cast(Father)d).eat();   // Workaround B, works as 
> expected
> int num3 = d.Father.eat();          // Workaround C, works as 
> well

Considering Father defines the function `int eat()` and Daughter 
defines the completely different function `int eat(int)`, it 
doesn't surprise me. You're not using virtual dispatch when you 
do `return super.eat` or `d.Father.eat()`, you're delegating the 
method call to the base class.