putting more smarts into a == b

[Frank Benoit]

Andrei Alexandrescu schrieb:
> Frank Benoit wrote:
>> Andrei Alexandrescu schrieb:
>>> Consider two objects a and b with a of class type. Currently, the
>>> expression a == b is blindly rewritten as a.opEquals(b). I argue it
>>> should be rewritten into a call to an (imaginary/inlined) function
>>> equalObjects(a, b), with the following definition:
>>>
>>> bool equalObjects(T, U)(T a, U b) if (is(T == class))
>>> {
>>>     static if (is(U == class))
>>>     {
>>>         if (b is null) return a is null;
>>>         if (a is null) return b is null;
>>>     }
>>>     else
>>>     {
>>>         enforce(a !is null);
>>>     }
>>>     return a.opEquals(b);
>>> }
>>>
>>> This hoists the identity test outside the opEquals call and also deals
>>> with null references. What do you think?
>>>
>>>
>>> Andrei
>>
>> What about interfaces?
> 
> Good question! What do they do now? I ran this:
> 
> interface A {}
> class Widget : A {}
> 
> void main() {
>     auto a = cast(A) new Widget;
>     A b = null;
>     writeln(a == b);
>     writeln(b == a);
> }
> 
> To my surprise, the program printed false twice. If I replace A with
> Widget inside main, the program prints false then crashes with the
> mythical segfault :o).
> 
> So how are interfaces compared?
> 
> 
> Andrei

Hm, i would have expected it not to compile, because A does not have
opEquals.

In DWT, I cast always first to Object.
Java> if( intf1.equals(intf2) ){
D1.0> if( ((cast(Object)intf1).opEquals( cast(Object)intf2 )){