The example was not some mindless example, and not even close to something like cast(bool)rand(). I consider the example I gave a well intended and unwitting example, which breaks transitivity via the current opEquals function. Basically, the intention is, if I have two items which implement an interface, then I should be able to compare those two items via the interface. A perfect example of this is the dcollections Map interface, I want to be able to compare for equality two maps, even if the implementations are different.
Say you had a collection that implemented the List and the Map interface (Like an ordered hash map). I should be able to compare that to a map or a list, but I can't compare the map and the list with each other. In fact, I would posit that unless lhs.opEquals and rhs.opEquals point to the exact same function, transitivity can be unwittingly broken. Actually, you could use this check instead of checking the typeinfos are equal when determining if you can call just one function because it covers more ground. -Steve ----- Original Message ---- > From: Andrei Alexandrescu <[email protected]> > To: Steve Schveighoffer <[email protected]> > Cc: Phobos <[email protected]> > Sent: Tue, April 27, 2010 5:29:04 PM > Subject: Re: [phobos] Issue with opEquals(Object, Object) > > On 04/27/2010 03:11 PM, Steve Schveighoffer wrote: > No loss there. > Transitivity is already not enforced by the current system. Of course. > One could after all return cast(bool) rand() from opEquals; no need for an > elaborate example. That doesn't mean we should espouse breakage of > transitivity. > My previous message shows that the proposed system is corrupt because it > breaks > transitivity by otherwise well-intended and unwitting > participants. Andrei _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
