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

[Timon Gehr]

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.

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