Interfaces allow member definitions?

[Frustrated]

On Thursday, 30 January 2014 at 15:28:24 UTC, Steven
Schveighoffer wrote:
> On Thu, 30 Jan 2014 09:31:05 -0500, Frustrated 
> <c1514843 at drdrb.com> wrote:
>
>
>> I'm not asking about a work around but if what I am talking 
>> about
>> can actually be done(does the vtable support this or can made 
>> to
>> support it?)
>
> Yes. Interfaces have no concrete vtable. Only classes do. A 
> concrete class can decide what the vtable has in it, and if you 
> had a "default" implementation, the compiler could stick that 
> in there. Note that the default implementation only can call 
> other member functions within the interface or module-level 
> functions, interfaces cannot access any derived data or members.
>
> Whether such a change would be accepted? No clue.
>
> -Steve

Basically I see no reason why the compiler can't treat the
interface as a class and allow "default" methods. (it would have
to allow multiple inheritance on that class though)

All it would do is make it easy to provide a default
implementation(more of a static implementation but allows it to
be overriden, which makes it useful).

For example, when creating a design you would no longer have to
specifically create a corresponding class to use for the
interface. You could just provide some default implementations of
everything(throw errors, write stuff, etc...)

I think it would be probably rather easy to do by extending the
vtable to have one lower level, the interface methods, which, in
fact, could use this(so you could have a this in them but only
reference other members of the interface).


Essentially what it boils down to is treating interfaces like
classes that have no fields). To avoid the diamond problem simply
always choose the method that is not from the interface(since it
is "default"), which is done naturally with the vtable.

Of course, maybe this just creates the diamond problem for
interfaces: "which default implementation to use"... which I'm
not sure if it's a problem?