Feedback on Átila's Vision for D

Alex sascha.orlov at gmail.com
Mon Oct 21 10:46:40 UTC 2019


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.

This is interesting. Can you provide a source of why the nominal 
type system is a contradiction to the current approach?
I mean, currently I can follow Meta more:
If you have an object implementing both, Debug and Display, then 
the class has to implement foo. And if it does, it can be handled 
by functions both handling Debug and Display. The ambiguity is 
solved at this level:

´´´
interface De{ void foo(); }
interface Di { void foo(); }
class C : De, Di{ override void foo(){} }
void main()
{
     auto c = new C();
     //c.fun1; //fails to compile, as you would expect
     De de = c;
     Di di = c;
     de.fun1;
     di.fun1;
}
auto fun1(De de){ de.foo; }
auto fun1(Di di){ di.foo; }
´´´

So, for sure, if you want to have different overloads for 
different interfaces, then, they can't go into the class of C. 
But there is no need to do so.


More information about the Digitalmars-d mailing list