A renewed call for interface methods with bodies

[Burton Radons]

(Hope this doesn't double-post)

Jesse Phillips Wrote:

> The problems of multiple inheritance is not related to overloaded 
> functions, but overridden functions. Whether that is what you meant or 
> not, that is still the problem. Your solution to the interface problem is 
> the exact solution that was avoid by not allowing multiple inheritance.

This has nothing to do with my proposal for interface methods with bodies (that is, it works correctly whether or not this problem is fixed), and I'm pretty sure the way it works now is a bug in the compiler, since there's no justification for it acting that way. Again and anon, my proposal does not modify overriding/overloading behaviour at all. It would if you could also use override:

	interface A
	{
		void foo ();
	}
	
	interface B : A
	{
		override void foo () { printf ("B\n"); }
	}
	
	interface C : A
	{
		override void foo () { printf ("C\n"); }
	}

	class D : B, C { }

THEN you would have a diamond problem. But since I haven't suggested that, even that case doesn't apply. Please bring examples if you're going to counter as I have the feeling we're talking at cross-purposes.

> Also, on a side note, c.A.foo() is very unclear, because that suggest 
> that A is an object in c with a function foo() that you wish to call, 
> which is highly inaccurate because c is an A.

It's consistent with other usages of "." in the language when it's used to constrain scope, a la "std.string.find", and it's legal to have code that acts like that (object.class.object) already. I think you're a little late to be arguing for syntactually discriminating usages of ".". But as I said, I don't care as the issue hasn't come up in the going on six years I've been using D as my primary language.