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

[Steven Schveighoffer]

On Tue, 30 Aug 2011 08:26:17 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 08/30/2011 07:13 AM, Timon Gehr wrote:
>> If there already is an implementation, it overrides it, otherwise it
>> implements it.
>
> That's pretty much it. The entire purpose of the "override" keyword is  
> to prevent silent bugs of two kinds:
>
> (a) User thinks she hooks a specific method but instead introduces a new  
> one.
>
> (b) User thinks she introduces a new method but instead hooks one.
>
> Override helps only in cases where otherwise a silent error would occur.  
> If the compiler issues an error message without the help of override,  
> override is unneeded and illegal. This is the case with interface and  
> abstract methods - "override" is emphatically unneeded because the  
> compiler/linker wouldn't allow the code anyway.

Your (a) and (b) points seem to be pointing to a different conclusion --  
that override should be required for interface methods.  Since  
implementing an interface method does not introduce a new method, it hooks  
the interface's existing one.

I personally think override should be required if it overrides an existing  
implementation, be rejected if it introduces a completely new symbol, and  
be optional if it implements an abstract method.  The latter rule is  
purely for code maintenance.  99%, no wait, I think 100% of the time, when  
a previously abstract base method grows an implementation after you have  
implemented it in a derived method, the remedy is simply adding override.   
This feels like annoyance that can be avoided by just putting override on  
it to begin with.  I can't think of a single case where I've implemented a  
function I *know* is callable by some base class symbol that I'd want to  
be informed when a base class implements it later on.  I don't care, I'm  
overriding it, no matter what the base class does (unless of course, the  
base class marks it final, but that would be an error anyways).

If the rule must be require or reject, I'd prefer requirement, even for  
interface methods.

-Steve