Bug 4088 – opEquals not called on interfaces

Given an interface that defines opEquals, the compiler will prefer to call the object.opEquals(Object, Object) on it. However, interfaces don't implicitly cast to Objects thanks to COM. example: interface I { bool opEquals(I other); } bool foo(I i1, I i2) { return i1 == i2; } testopequals.d(8): Error: function object.opEquals (Object lhs, Object rhs) is not callable using argument types (I,I) testopequals.d(8): Error: cannot implicitly convert expression (i1) of type testopequals.I to object.Object testopequals.d(8): Error: cannot implicitly convert expression (i2) of type testopequals.I to object.Object And can someone add 2.042 and 2.043 to the version list? This is tested on 2.043.

Note, this is a problem for dcollections 2.0: http://www.dsource.org/projects/dcollections/ticket/4

Created attachment 907 Proposed fix It is actually a very surprising bug, that interfaces can't be compared as it might break structs due to the compiler generated opEquals. The attached patch does an explicit cast to Object. This would still not work with C++/COM interfaces.

Can't dmd just check the "type" of a given interface and only allow implicit casts to Object if it is a normal one, i.e. no COM and no C++ interface?

(In reply to comment #3) > Can't dmd just check the "type" of a given interface and only allow implicit > casts to Object if it is a normal one, i.e. no COM and no C++ interface? I'm not familiar with the internals of the compiler, but I believe this is true. I think it should be statically verifiable that an interface is a COM interface, and then opEquals can be handled differently. However, we continue to get silence from Walter on this...

I think this should be tackled at a deeper level, probably somewhere around MATCH TypeClass::implicitConvTo(Type *to) in mtype.c to allow implicit conversions of interfaces to Object in general. Then also this works: void foo(Object o) {} Interface i; foo(i); // or Object o = i;

*** Issue 2794 has been marked as a duplicate of this issue. ***

I'm not at all sure the patch is the right solution to this.

Issues that need to be resolved: 1. what should happen if this is called with a COM object? 2. how does an opEquals defined in an interface interact with the object.opEquals? 3. a forced cast, unlike an implicit cast, is a blunt instrument that can do a lot more than simply cast an interface to its base class. If the arguments are other types, what are the conseqences of this forced cast? A change of this sort needs to resolve these issues, and have test cases to verify them.

(In reply to comment #8) > Issues that need to be resolved: > > 1. what should happen if this is called with a COM object? Compiler error. > 2. how does an opEquals defined in an interface interact with the > object.opEquals? If the notion of COM interfaces is specialized, then standard interfaces do not need to define opEquals, it's assumed that any standard interface (not C++ or COM) derives from Object, and implicit dynamic casting to Object to do opEquals should work. > 3. a forced cast, unlike an implicit cast, is a blunt instrument that can do a > lot more than simply cast an interface to its base class. If the arguments are > other types, what are the conseqences of this forced cast? An implicit cast to Object would be the best remedy. However, the issue of dynamic casting and blunt casting being conflated would be a good issue to solve too.

https://github.com/D-Programming-Language/druntime/pull/72 (In reply to comment #8) > 1. what should happen if this is called with a COM object? If two interfaces are identity comparable, returns its result. Otherwise, downcast to Object, and the result is false. And this rule also appleied to C++ interface (COM interface is C++ interface, and the downcasting from C++ interface to Object returns always null). > 2. how does an opEquals defined in an interface interact with the > object.opEquals? An interface's opEquals is not used directly. Object.opEquals is always used for the interface comparison when it is possible. > 3. a forced cast, unlike an implicit cast, is a blunt instrument that can do a > lot more than simply cast an interface to its base class. If the arguments are > other types, what are the conseqences of this forced cast? Same as Steven's comment in #9.

This is also the root cause of bug 7451.

It think the proposal in #5459 goes into the right direction. One point of it is to prefer interface opEquals over a downcast. Also, if an interface had an opEquals with a different signature, then Object.opEquals becomes hidden. interface IA { bool opEquals(IA o); } class A { bool opEquals(IA o) { return false; } }

*** Issue 7451 has been marked as a duplicate of this issue. ***

Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/9c8b88ca89afef97a5d3b81ba7bd65cac71fd6d0 fix Issue 4088 - opEquals not called on interfaces

Reopened because now implicit interface comparison is fixed, but having opEquals in interfaces still doesn't work.

Unless the checked-in fix doesn't allow two interfaces to compare, this bug should be closed. It is about the difference between comparing two objects and comparing two interfaces. Prior to this fix, you con't compare two interfaces *period*, even if they defined an identical signature to Object.opEquals. I feel that it should be possible to specialize opEquals for interfaces and objects, but this is a separate problem (and actually an enhancement). IIUC, the applied fix makes it so Objects and interfaces compare in the same way. If I find I can compare two interfaces in the same way I can compare two objects, I'll close this as resolved, and you may open a different bug regarding adding the enhancement of overriding the default behavior of object.opEquals.

If there's another issue, please open a new bug report, and please provide an example of the failing code.

Restoring resolution, this was fixed after all.

*** Issue 5459 has been marked as a duplicate of this issue. ***