"The last feature": overridable methods in interfaces

[Andrei Alexandrescu]

Lars T. Kyllingstad wrote:
> 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?

Ambiguity error.

> I thought 
> multiple subtyping without multiple inheritance was the raison d'être 
> for interfaces.

Interfaces do foster multiple inheritance!

Andrei