No loss there. Transitivity is already not enforced by the current system.
An example:
interface I1
{
int getX();
}
interface I2
{
int getX();
}
class C1 : I1
{
int x;
int getX() { return x; }
bool opEquals(Object o)
{ if(auto n = cast(I1)o) return x == n.getX(); return false; }
}
class C2 : I2
{
int x;
int getX() { return x; }
bool opEquals(Object o)
{ if(auto n = cast(I2)o) return x == n.getX(); return false; }
}
class C3 : I1, I2
{
int x;
int getX() { return x; }
bool opEquals(Object o)
{
if(auto n = cast(I1)o) return x == n.getX();
if(auto n = cast(I2)o) return x == n.getX();
return false;
}
}
This would lead me to conclude the *only* provably transitive opEquals starts
with:
if(auto n = cast(typeof(this))other)
which is quite limited IMO.
-Steve
----- Original Message ----
> From: Andrei Alexandrescu <[email protected]>
> Let's suppose we allow
> the feature above. Then a StevesTextWidget can claim equality with a
> TextWidget
> in spite of the latter's opposition. But then a WaltersTextWidget could also
> claim equality with the same TextWidget, again in spite of the latter's
> opposition. But then StevesTextWidget may not compare equal with
> WaltersTextWidget, which would break transitivity.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
