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

[Steven Schveighoffer]

On Tue, 30 Aug 2011 13:06:02 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:

> On 08/30/2011 06:43 PM, Steven Schveighoffer wrote:
>> On Tue, 30 Aug 2011 12:29:59 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> On 8/30/11 11:06 AM, Steven Schveighoffer wrote:
>>>> When I write code that derives from a base class, I'm declaring with
>>>> override that I want to implement the base class' function.
>>>> When I write code that implements an interface, I'm declaring with
>>>> override that I want to implement the interface's function.
>>>
>>> From the cycle "deadpan answers": I think one should use "override"
>>> when one wants to override.
>>
>> Then your description of cases where override helps prevent bugs should
>> reflect that:
>>
>> (a) User thinks she overrides a specific method but instead introduces a
>> new one.
>>
>> (b) User thinks she introduces a new method but instead overrides one.
>>
>> I consider implementing an interface method to be hooking, since you are
>> hooking calls from said interface.
>>
>> I guess if we want to avoid solving all hooking problems, even those
>> where one does not intend to implement an interface, but accidentally
>> does, or introduce large annoyances where someone changes a widely used
>> interface to an abstract class, then I guess the status quo is good.
>>
>> -Steve
>
> I don't think that you can change a widely used interface into an  
> abstract class and not introduce annoyances much larger than override is  
> capable of creating.

interface I
{
    int foo();
    void bar();
}

->

interface _I
{
    int foo();
    void bar();
}

abstract class I : _I
{
    int foo() { return 0; }
}

Now, everywhere I was implemented before has to change all their  
implementations of foo() to override, just to compile.

There may be some cases where classes already  had a base class, but it  
depends on the context of where I is implemented.  However, in 100% of the  
cases, putting override on each implementation of foo does *not* result in  
a bug.

My point is, what "bug" is it preventing by rejecting override when  
implementing an interface?  The only "bug" I see is that you didn't put  
override in the signature.  That translates to an annoyance, not a real  
bug.

> How does the status quo prevent implementing interface methods by  
> accident?

It doesn't.  That was my point.

-Steve