Feedback on Átila's Vision for D

[Meta]

On Sunday, 20 October 2019 at 19:58:28 UTC, Max Samukha wrote:
> On Sunday, 20 October 2019 at 17:46:07 UTC, Meta wrote:
>
>>
>> I'm not saying that allowing to differentiate between 
>> implementations would be worthless, just that it's not a bug 
>> that D collapses them into 1 in the implementing class.
>
> I still do not follow why the diamond problem and the lack of 
> data members is relevant. For me, it is not different from:
>
> struct A {
>     int x;
> }
>
> struct B {
>     int x;
> }
>
> Both types are isomorphic to int, but we still consider them 
> distinct types and x's inside them unrelated, even though they 
> are typed and named identically.

That's not really a correct analogy, because A and B are carrying 
mutable state. As I said, interfaces carry no state. Let's 
imagine that they could:

interface A { int n; void setN(int n); int getN(); }
interface B { int n; void setN(int n); int getN(); }

class C: A, B
{
     //Does super refer to A here, or B?
     override void setN(int n) { this.n = n; }
     override void getN() { return this.n; }
}

If this was possible in the language, it would become VERY 
important to be able to specify which interface you were 
implementing getN and setN for, because now this code would do 
something different depending on whether `this.n` refers to A's n 
member or B's:

void takesA(A a) { writeln("Got an A with n = ", a.getN()); }

void takesB(B b) { writeln("Got a B with n = ", b.getN()); }

C c = new C();
c.setN(10); //Is A.n set or B.n?

//What do these methods print? What should they?
takesA(c);
takesB(c);

This should hopefully make more clear why the fact that 
interfaces carry no mutable state means that it doesn't matter 
whether C.setN / C.getN refers to C.A.getN/setN or C.B.getN/setN.

Now, as has been pointed out, A's getN / setN methods may carry a 
different semantic meaning from B's (or, to go back to the 
original example, Display.fmt may _mean_ something very different 
from Debug.fmt). In that light, it would probably be useful to be 
able to tell the compiler that you want a different 
implementation for one interface method vs. the other, even 
though they have the exact same method signatures.