"The last feature": overridable methods in interfaces

[Don]

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.
> 
> 
> Andrei

I don't understand this. How does belowTop() know how to call top()? It 
has the 'this' pointer, so that does have a pointer to the vtable; but 
since it doesn't know the inheritance hierarchy of the object which it 
applies to, how can it know which vtable index to use?
With 'final' functions, of course there's no problem.
It can be solved with thunks, of course, but I presume that's not the 
intention?