A renewed call for interface methods with bodies

[Burton Radons]

Ary Borenszweig Wrote:

> Burton Radons escribió:
> > BCS Wrote:
> > 
> >> Burton Radons wrote:
> >> [...]
> >>
> >>
> >> something just occurred to me:
> >>
> >> The only actions that a function body in an interfaces could do to 
> >> "this" is function calls that would have to be virtual (or how could it 
> >> ever do anything) however the code generated for a interface method 
> >> needs to know the type of the object to be able to make the calls 
> >> correctly. The only reasonable way I can see to let interface functions 
> >> have bodies would be to in effect use a mixin.
> >>
> >> Can anyone think of a better solution?
> > 
> > There aren't any problems in compiling interface methods with bodies - it's exactly the same as a class with abstract methods.
> 
> Doesn't that lead to multiple inheritance, with all its complexities?

Even if it did - and it won't, because D's function overloading prohibits these kind of games - it would be a tenth the complexity of C++'s MI, most of which is made complex because you need to handle inheritance diamonds of fields:

	struct A
	{
		int value;
	}
	
	struct B : A
	{
		void set16 () { value = 16; }
	}
	
	struct C : A
	{
		void set32 () { value = 32; }
	}
	
	struct D : B, C
	{
	}
	
	D d;
	d.set16 ();
	d.set32 ();
	// What is d.value?

This requires some truly mind-melting compiling and arbitrary language design to allow it to work. But when limited to only methods, as in interfaces, it's a simple matter to do C++-style function overloading. However, that's not how D does function overloading; in D competition is not allowed between scopes, and I think that's fine and should be more rigorously enforced than it is.