interface A {}
class B:A {}

void main() {
A x = new B();
A y = new B();
assert(x!=y);	// ok
printf("1. ok\n");

B[] u, v;
u ~= new B();
v ~= u;
assert(u==v);	// ok
printf("2. ok\n");

A[] a, b;
a ~= new B();
b ~= a;
assert(b==a);	// SEGFAULT!
printf("3. ok\n");
}

//It should be possible to compare interface-type-arrays for equality //since all array elements inherit opEquals from Object.

jmjmak@utu.invalid.fi schrieb:
> interface A {}
> class B:A {}
> 
> void main() {
> A x = new B();
> A y = new B();
> assert(x!=y);	// ok
> printf("1. ok\n");
> 
> B[] u, v;
> u ~= new B();
> v ~= u;
> assert(u==v);	// ok
> printf("2. ok\n");
> 
> A[] a, b;
> a ~= new B();
> b ~= a;
> assert(b==a);	// SEGFAULT!
> printf("3. ok\n");
> }
> 
> //It should be possible to compare interface-type-arrays for equality //since all array elements inherit opEquals from Object.

http://digitalmars.com/d/interface.html
 #
 # Interfaces cannot derive from classes; only from other interfaces.
 #

Thomas

<jmjmak@utu.invalid.fi> wrote in message news:df4t72$27kf$1@digitaldaemon.com...
> interface A {}
> class B:A {}
>
> void main() {
> A x = new B();
> A y = new B();
> assert(x!=y); // ok
> printf("1. ok\n");
>
> B[] u, v;
> u ~= new B();
> v ~= u;
> assert(u==v); // ok
> printf("2. ok\n");
>
> A[] a, b;
> a ~= new B();
> b ~= a;
> assert(b==a); // SEGFAULT!
> printf("3. ok\n");
> }
>
> //It should be possible to compare interface-type-arrays for equality //since all array elements inherit opEquals from Object.
>
>

arrays of objects and interfaces are IMHO messed up in D.
See for example
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/4715
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3681
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/24077

I think what's happening in your example is that the array equality routine is assuming the interface ptr is the same as the object ptr and so it gets an invalid dereference. It should work if you don't have arrays of interfaces but instead have arrays of Object and cast the interface to an Object.

Ben Hinkle wrote:
> <jmjmak@utu.invalid.fi> wrote in message news:df4t72$27kf$1@digitaldaemon.com...
<snip>
>> A[] a, b;
>> a ~= new B();
>> b ~= a;
>> assert(b==a); // SEGFAULT!
>> printf("3. ok\n");
>> }
>>
>> //It should be possible to compare interface-type-arrays for equality
>> //since all array elements inherit opEquals from Object.
> 
> arrays of objects and interfaces are IMHO messed up in D.
> See for example
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/4715
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3681
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/24077

And don't forget

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1726
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3287

> I think what's happening in your example is that the array equality routine is assuming the interface ptr is the same as the object ptr and so it gets an invalid dereference. It should work if you don't have arrays of interfaces but instead have arrays of Object and cast the interface to an Object. 

It's an array of an interface.  It shouldn't be trying to compare it as if it's an array of a class.  The compiler is confusing the two.  Bona fide bug.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.

Thomas Kühne wrote:
<snip>
>> //It should be possible to compare interface-type-arrays for equality
>> //since all array elements inherit opEquals from Object.
> 
> http://digitalmars.com/d/interface.html
>  #
>  # Interfaces cannot derive from classes; only from other interfaces.
<snip>

I would've expected Object to be an exception to this.  Or if not, then that every interface implicitly contains an opEquals that points to an appropriate opEquals of the classes that implement it.

But instead, it seems to be just comparing the object references, which is most certainly wrong.  This fails in gdc (0.11?):

    interface A {}

    class B : A {
        int opEquals(Object o) {
                return true;
        }

        int opEquals(A a) {
                return true;
        }

        int opEquals(B b) {
                return true;
        }
    }

    void main() {
        A a = new B;
        A b = new B;
        assert (a == a);
        assert (a == b);
    }

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

> And don't forget
>
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1726

Lack of covariance with interfaces isn't a bug IMO. It's a limitation but not a bug.

> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3287


This one looks like a bug if indeed the compiler doesn't complain about trying to use an interface with covariance. Interfaces and covariance should always generate compiler errors.

Ben Hinkle wrote:
>> And don't forget
>>
>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1726
> 
> Lack of covariance with interfaces isn't a bug IMO. It's a limitation but not a bug.
<snip>

If so, then it's a totally arbitrary restriction.  And it would need to be documented.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:df9okd$pj5$2@digitaldaemon.com...
> Ben Hinkle wrote:
>>> And don't forget
>>>
>>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1726
>>
>> Lack of covariance with interfaces isn't a bug IMO. It's a limitation but not a bug.
> <snip>
>
> If so, then it's a totally arbitrary restriction.

well... to me something totally arbitrary would be, for example, saying classes with names starting with the letter Q can't be covariant. But interface references and object references are quite different beasts (as your posts indicate) so it isn't surprising to me at all that interfaces aren't covariant or have different behaviors than object references. Is it unfortunate? yes. Is it unreasonable? no. Is it fixable? maybe - I don't know.

>  And it would need to  be documented.

agreed (along with plenty of other undocumented behaviors)

Ben Hinkle wrote:
<snip>
> well... to me something totally arbitrary would be, for example, saying classes with names starting with the letter Q can't be covariant. But interface references and object references are quite different beasts (as your posts indicate) so it isn't surprising to me at all that interfaces aren't covariant or have different behaviors than object references.

This has nothing to do with the relative behaviours of interface and object _references_.  That only affects the other issue.

> Is it unfortunate? yes. Is it unreasonable? no. Is it fixable? maybe - I don't know.

My answer would be "yes" to all three questions.  And it should be a simple fix.  It just a matter of the compiler determining that an interface method is implemented in the same way as it determines that a class method is overridden.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:df9uhn$109h$1@digitaldaemon.com...
> Ben Hinkle wrote:
> <snip>
>> well... to me something totally arbitrary would be, for example, saying classes with names starting with the letter Q can't be covariant. But interface references and object references are quite different beasts (as your posts indicate) so it isn't surprising to me at all that interfaces aren't covariant or have different behaviors than object references.
>
> This has nothing to do with the relative behaviours of interface and object _references_.  That only affects the other issue.

I'm lost. The problem with, for example, returning an interface reference when the base class is declared to return an object reference is that interface references and object references aren't interchangable. They point to different memory locations. So I don't see why you say the lack of interface covariance has nothing to do with the references - it is exactly because of the references.

>> Is it unfortunate? yes. Is it unreasonable? no. Is it fixable? maybe - I don't know.
>
> My answer would be "yes" to all three questions.  And it should be a simple fix.  It just a matter of the compiler determining that an interface method is implemented in the same way as it determines that a class method is overridden.

I know these things have come up in the past. For example http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/9108. Please state what the "simple fix" is in more detail because I don't see how you can make interfaces covariant with classes. Remember covariance relies on the transformation from one type to the another as generating *no code*. An object reference to a derived class can be converted to an object reference to a base class with no code generated. The same is not true for anything involving interfaces.