method returning child, doesn't overrides declared method returning parent

[Jonathan M Davis]

On Tuesday, August 30, 2011 06:47:03 Steven Schveighoffer wrote:
> On Mon, 29 Aug 2011 16:24:46 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > On Monday, August 29, 2011 14:09 Mariusz Gliwiński wrote:
> >> <code>
> >> interface Interface {
> >> Interface method();
> >> }
> >> class Class : Interface {
> >> override Class method() {}
> >> }
> >> </code>
> >> 
> >> DMD complains it isn't overriding. How should it be according to
> >> specification, and how about making it legal?
> > 
> > It's _not_ overriding. It's implementing an interface method. Those are
> > two
> > totally different things. And I think that it's horrible that Java
> > considers
> > implementing an interface method as overriding it. I'd _hate_ to see
> > that in
> > D.
> 
> Then this must be a bug?
> 
> interface I
> {
>    void foo();
> }
> 
> class C : I
> {
>     override void foo(); // compiles
> }
> 
> I feel override should be *allowed* when implementing interface functions
> (but not required).  Otherwise, you get into situations where a base class
> decides to become abstract (doesn't implement a function), but a derived
> class is specifying override (especially if override is required, as is
> planned), if that's a compiler error, I think it's a useless error.

I think that override belongs on functions which actually override base class 
functions. It should be required when a function overrides a base class 
function, and it should be disallowed when it's on a function that doesn't 
override a base class function. Interfaces have nothing to do with it.

The whole point of override is to make sure that you know when your function 
is or isn't overriding a base class function. Ff the base class changes, then 
that's extremely relevant to the derived class, and it _should_ error out if 
the function is no longer marked as it should be (be it that it has override 
when it shouldn't or that it doesn't have it when it should). That way, you 
never have functions which override when you didn't mean them to (e.g. if a 
new function were added to one of its base classes), and you never have a 
function which _doesn't_ override when you mean it to (e.g. when a function 
was removed from one or more of its base classes).

- Jonathan M Davis