"The last feature": overridable methods in interfaces

[Lars T. Kyllingstad]

Andrei Alexandrescu wrote:
> Walter has now implemented final methods in interfaces and also 
> contracts in interfaces, both of which I think are just awesome.
> 
> We figured that essentially he artificially disallows interfaces from 
> providing bodies for methods. I think that's a gratuitous limitation; 
> the only distinguishing quality of an interface is that it has no state. 
>  Other than that, interfaces can always offer overridable functions that 
> by default offer functionality in terms of existing interface functions. 
> For example:
> 
> interface Stack(T)
> {
>     void push(T);
>     void pop();
>     @property ref T top();
>     @property bool empty();
>     T belowTop()
>     {
>         auto t = top;
>         pop();
>         auto result = top;
>         push(t);
>     }
> }
> 
> The default implementation of belowTop does a fair amount of work. A 
> particular implementation might just use that or override it with a more 
> efficient implementation.
> 
> Many more examples can be imagined, but I'm looking for a killer one, or 
> perhaps a killer counterexample (e.g. when would an interface-defined 
> method be really bad?)
> 
> Your thoughts welcome.

What happens when two interfaces implement the same method?  I thought 
multiple subtyping without multiple inheritance was the raison d'être 
for interfaces.

-Lars