On Sun, 27 Sep 2009 10:32:29 -0400, Andrei Alexandrescu <seewebsiteforem...@erdani.org> wrote:

Frank Benoit wrote:
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 )){

I think in D the cast is inserted automatically. Walter?

From the assembly, it appears that the compiler is comparing the reference values directly. Which is not what you want, you want the opEquals from Object.

-Steve

Reply via email to