Feedback on Átila's Vision for D

[Exil]

On Monday, 21 October 2019 at 12:34:14 UTC, Meta wrote:
> On Sunday, 20 October 2019 at 20:41:01 UTC, Exil wrote:
>> Sure, one can argue that it's not a bug, auto-decoding isn't a 
>> bug, in fact it was very much intentional. But I think we'd 
>> all be better off without it. The way it is implemented can 
>> lead to bugs quite easily. Since it picks whichever one based 
>> on order.
>
> Show me a concrete example. Also, there is no "picking" of 
> which interface method is implemented. Both are implemented by 
> the same method.

interface OneThing {
     void foo(); // should do One thing
}

interface AnotherThing {
     void foo(); // do another thing
}

class A : OneThing, AnotherThing {
     override void foo() { }
}


void bar(OneThing o) {
    o.foo(); // do something unrelated to AnotherThing
}

void tar(AnotherThing a) {
    a.foo(); // do something unrelated to OneThing
}


void main() {
     A a = new A;

     bar(a);
     tar(a);
}


Your assumption is that just because the functions are named the 
same thing then they should do the exact same thing. Sure you can 
avoid naming conflict when you have to, but if you are using two 
libraries you didn't write then you can't make those kinds of 
decisions.


>> None of this is obvious.
>
> I agree. I was surprised as well when I first learned about 
> this, but that doesn't mean it's incorrect.

Technically nothing is incorrect. Auto decoding isn't incorrect. 
If that's how you view things in coding, as black and white, you 
can make that same argument against virtually everything. 
Surprises lead to bugs. Surprises that differ from how the rest 
of the language operates are even bigger surprises. Those kind of 
surprises can take hours to try to figure out what is going 
wrong. If you have an ambiguous call you get an error. The 
compiler doesn't choose one based on which one was defined first.

>> Rationale like your's is why the bug reports like this one 
>> remain open for 9+ years and it never gets fixed. It's not a 
>> bug it's a feature! Therefore any change is an enhancement and 
>> requires a DIP.
>
> There's this other language called Java that you may have heard 
> of, that does things the exact same way, and the many millions 
> of programmers that use that language seem to have no issue 
> with this behaviour. I've already agreed that it would be worth 
> having a way to write a different implementation for different 
> interfaces with the same method, but that is the very 
> *definition* of an enhancement.

Java isn't exactly the best language to look at. It's usually 
people's first language and then they just stick with it cause 
it's what they know. If you want to look at Java as an example 
for why something should be the way it is. Java doesn't have 
operator overloading. Anyways an easy counter example is that C# 
allows you to override the functions separately.

You can call it whatever you want. It doesn't change the fact 
this will just stay the way it is for another 9 years because 
people would rather sweep it under the rug due to ambiguity than 
fix it. Sure it's an edge case, but there's so many places in D 
where edges like this have questionable implementations, they 
start to add up.