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 # # Interfaces cannot derive from classes; only from other interfaces. # 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 # # Interfaces cannot derive from classes; only from other interfaces.

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 digitalmars.D.bugs/4715 digitalmars.D.bugs/3681 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...

 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 digitalmars.D.bugs/4715 digitalmars.D.bugs/3681 digitalmars.D/24077

And don't forget digitalmars.D.bugs/1726 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

 digitalmars.D.bugs/1726

Lack of covariance with interfaces isn't a bug IMO. It's a limitation but not a bug.
 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

 digitalmars.D.bugs/1726

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

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

 digitalmars.D.bugs/1726

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

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 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.

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 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.

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.

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 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.

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.

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 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.

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

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:

 Why are these all nocompile?

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

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