www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Equality bug with interfaces

reply jmjmak utu.invalid.fi writes:
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.
Aug 31 2005
next sibling parent reply =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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




Thomas

-----BEGIN PGP SIGNATURE-----

iD8DBQFDFg7Z3w+/yD4P9tIRAqUnAKCg/Dq70rwLXnvEK22/ijY7fmJQwQCgvX0O
6b6SzwMIIolzq0w07wO2GLA=
=hKDn
-----END PGP SIGNATURE-----
Aug 31 2005
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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




<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.
Sep 02 2005
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
<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.
Aug 31 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Sep 02 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 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.
Sep 02 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Sep 02 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"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)
Sep 02 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Sep 02 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"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.
Sep 02 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Ben Hinkle wrote:
<snip>

 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.


The post you quoted the link to has only one thing to do with returning 
interface references, namely that _one_ of the interface functions 
returns an interface reference.  But the basic issue raised there is 
that which is still present by removing hjkl from the code sample.

----------
class Yuiop {}

interface Qwert {
     Yuiop zxcvb();
}

class Asdfg : Yuiop, Qwert {
     Asdfg zxcvb() { return null; }
}
----------

Now returning an interface reference doesn't factor into the equation in 
any way, shape or form.  And the compiler error still shows.  And even 
in the original post, you still could've noticed that the compiler 
complains about zxcvb as well.


 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.


<snip>

How does the compiler know that a method overrides one in a base class?

It has semantically analysed the base class definition, and generated 
its vtbl and a symbol table mapping the method names and signatures of 
the base class to vtbl slots.

When it comes to the derived class, as it fills in the vtbl it checks 
the base class symbol table to see if any function with the same name 
and matching signature exists in the base class.  When one matches, 
either exactly or by covariance, it uses the same vtbl slot as the base 
class did, so that it really does override.

The way I expect interfaces are implemented is that every class that 
implements an interface has, as well as its regular vtbl, a vtbl for 
each interface it implements.  If a class implements one or more 
interfaces, either directly or by being derived from a class that does, 
it looks up the signature in the symbol table of each of its interfaces, 
and fills in the slot in its interface vtbl.  All it needs to do is to 
count covariant matches when doing this, just as it does when overriding 
in a class.

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.
Sep 02 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
news:dfa5eu$17le$1 digitaldaemon.com...

 Ben Hinkle wrote:
 <snip>

 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.


 The post you quoted the link to has only one thing to do with returning 
 interface references, namely that _one_ of the interface functions returns 
 an interface reference.  But the basic issue raised there is that which is 
 still present by removing hjkl from the code sample.

 ----------
 class Yuiop {}

 interface Qwert {
     Yuiop zxcvb();
 }

 class Asdfg : Yuiop, Qwert {
     Asdfg zxcvb() { return null; }
 }
 ----------

 Now returning an interface reference doesn't factor into the equation in 
 any way, shape or form.  And the compiler error still shows.  And even in 
 the original post, you still could've noticed that the compiler complains 
 about zxcvb as well.


Oh, OK. I was just looking at the hjkl example. I agree there shouldn't be 
any technical challenge to having the above example work.


 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.


 <snip>

 How does the compiler know that a method overrides one in a base class?

 It has semantically analysed the base class definition, and generated its 
 vtbl and a symbol table mapping the method names and signatures of the 
 base class to vtbl slots.

 When it comes to the derived class, as it fills in the vtbl it checks the 
 base class symbol table to see if any function with the same name and 
 matching signature exists in the base class.  When one matches, either 
 exactly or by covariance, it uses the same vtbl slot as the base class 
 did, so that it really does override.

 The way I expect interfaces are implemented is that every class that 
 implements an interface has, as well as its regular vtbl, a vtbl for each 
 interface it implements.  If a class implements one or more interfaces, 
 either directly or by being derived from a class that does, it looks up 
 the signature in the symbol table of each of its interfaces, and fills in 
 the slot in its interface vtbl.  All it needs to do is to count covariant 
 matches when doing this, just as it does when overriding in a class.


Gotcha. I agree.
Sep 02 2005
parent jmjmak utu.invalid.fi writes:
In article <dfa7b4$19c3$1 digitaldaemon.com>, Ben Hinkle says...

"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
news:dfa5eu$17le$1 digitaldaemon.com...

 Ben Hinkle wrote:
 <snip>

 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.


 The post you quoted the link to has only one thing to do with returning 
 interface references, namely that _one_ of the interface functions returns 
 an interface reference.  But the basic issue raised there is that which is 
 still present by removing hjkl from the code sample.

 ----------
 class Yuiop {}

 interface Qwert {
     Yuiop zxcvb();
 }

 class Asdfg : Yuiop, Qwert {
     Asdfg zxcvb() { return null; }
 }
 ----------

 Now returning an interface reference doesn't factor into the equation in 
 any way, shape or form.  And the compiler error still shows.  And even in 
 the original post, you still could've noticed that the compiler complains 
 about zxcvb as well.


Oh, OK. I was just looking at the hjkl example. I agree there shouldn't be 
any technical challenge to having the above example work.


 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.


 <snip>

 How does the compiler know that a method overrides one in a base class?

 It has semantically analysed the base class definition, and generated its 
 vtbl and a symbol table mapping the method names and signatures of the 
 base class to vtbl slots.

 When it comes to the derived class, as it fills in the vtbl it checks the 
 base class symbol table to see if any function with the same name and 
 matching signature exists in the base class.  When one matches, either 
 exactly or by covariance, it uses the same vtbl slot as the base class 
 did, so that it really does override.

 The way I expect interfaces are implemented is that every class that 
 implements an interface has, as well as its regular vtbl, a vtbl for each 
 interface it implements.  If a class implements one or more interfaces, 
 either directly or by being derived from a class that does, it looks up 
 the signature in the symbol table of each of its interfaces, and fills in 
 the slot in its interface vtbl.  All it needs to do is to count covariant 
 matches when doing this, just as it does when overriding in a class.


Gotcha. I agree. 


Good then, I didn't wan't to cause any serious fight here :) I can probably live
with the restrictions in the D spec. Hopefully this detail gets documented AND
also implemented in the compiler (those anonymous segfaults in a high level
language really don't sound good.)

Jari-Matti
Sep 02 2005
prev sibling parent reply =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.


Added to DStress as
http://dstress.kuehne.cn/nocompile/o/opCmp_06_A.d
http://dstress.kuehne.cn/nocompile/o/opCmp_06_B.d
http://dstress.kuehne.cn/nocompile/o/opCmp_06_C.d
http://dstress.kuehne.cn/nocompile/o/opCmp_06_D.d
http://dstress.kuehne.cn/nocompile/o/opCmp_06_E.d
http://dstress.kuehne.cn/nocompile/o/opCmp_06_F.d
http://dstress.kuehne.cn/nocompile/o/opCmp_06_G.d
http://dstress.kuehne.cn/nocompile/o/opCmp_06_H.d
http://dstress.kuehne.cn/nocompile/o/opCmp_06_I.d
http://dstress.kuehne.cn/nocompile/o/opCmp_06_J.d
http://dstress.kuehne.cn/nocompile/o/opCmp_06_K.d
http://dstress.kuehne.cn/nocompile/o/opCmp_06_L.d
http://dstress.kuehne.cn/nocompile/o/opCmp_06_M.d
http://dstress.kuehne.cn/nocompile/o/opCmp_06_N.d
http://dstress.kuehne.cn/nocompile/o/opCmp_06_O.d

Thomas

-----BEGIN PGP SIGNATURE-----

iD8DBQFDH2wz3w+/yD4P9tIRArUeAJ9ufWCDHOD/VvoNvzJnlXx7b+gKFwCfVx/O
yHzmV3MGi8GQqQlE3KadS7s=
=WZS4
-----END PGP SIGNATURE-----
Sep 07 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Thomas Kühne wrote:
<snip>

 Added to DStress as
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_A.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_B.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_C.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_D.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_E.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_F.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_G.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_H.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_I.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_J.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_K.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_L.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_M.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_N.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_O.d


<snip>

Why are these all nocompile?  And what is the test function for - just a 
dummy function to avoid any special handling of empty interfaces?

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.
Sep 08 2005
parent reply =?ISO-8859-1?Q?Thomas_K=FChne?= <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stewart Gordon schrieb:

 Thomas Kühne wrote:
 <snip>
 

 Added to DStress as
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_A.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_B.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_C.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_D.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_E.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_F.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_G.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_H.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_I.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_J.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_K.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_L.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_M.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_N.d
 http://dstress.kuehne.cn/nocompile/o/opCmp_06_O.d


 
 <snip>
 
 Why are these all nocompile?


Interfaces neither inherite Object's opCmp nor define their own.


  And what is the test function for - just a
 dummy function to avoid any special handling of empty interfaces?


Yes

Thomas
-----BEGIN PGP SIGNATURE-----

iD8DBQFDIBzs3w+/yD4P9tIRAhSwAJ4ivtXke+ngvJ6l4We0HJZILt+tdQCeM9T1
pblGyKnLHuyls0YdE88+l00=
=hhn4
-----END PGP SIGNATURE-----
Sep 08 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Thomas Kühne wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Stewart Gordon schrieb:


<snip>

 Why are these all nocompile?


 
 Interfaces neither inherite Object's opCmp nor define their own.


<snip>

Primitive types don't have opEquals or opCmp either.  So if that's the 
reason, then surely

     int a, b;
     ...
     assert (a == b);
     assert (a < b);

would be equally illegal.

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.
Sep 08 2005
parent =?ISO-8859-1?Q?Thomas_K=FChne?= <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stewart Gordon schrieb:


 Thomas Kühne wrote:
 

 Stewart Gordon schrieb:


 
 <snip>
 

 Why are these all nocompile?



 Interfaces neither inherite Object's opCmp nor define their own.


 
 <snip>
 
 Primitive types don't have opEquals or opCmp either.  So if that's the
 reason, then surely
 
     int a, b;
     ...
     assert (a == b);
     assert (a < b);
 
 would be equally illegal.


http://www.digitalmars.com/expression.html#RelExpression
Does mention int.., float... and object, but leaves out the interfaces.

Thomas



-----BEGIN PGP SIGNATURE-----

iD8DBQFDIdN53w+/yD4P9tIRArrDAKCVZBb1dG/En7kYXOAHSavvyrpO4wCghf9t
T1anNw4l+wXd/YwlPt3jfSI=
=FiOO
-----END PGP SIGNATURE-----
Sep 09 2005