Andrei Alexandrescu <seewebsiteforem...@erdani.org> wrote: >> It creates very awkward relationships between the suite of operators >> which is likely to break down in many logical constructs. > > Doesn't seem that drastic to me. > >> I don't understand; your example is the perfect example of why opCmp==0 >> should be the default opEquals, but somehow it's an argument against? I >> have no idea how to reason about this topic.. > > You yourself seemed to reach for an operator ===. In fact those > comparisons you think should exist already exist: what you claim "==" > should be is really !(a < b) && !(b < a) or !opCmp(a, b); and what you > think "===" should be is really "==". > >> I come from a place where <,<=,==,!=,>=,> are a suite, and it is >> reasonable to assume they all work the same. > > I think that place is not a good place. That's not a reasonable assumption. > >> Is that not the default >> presumption of modern programmers? > > No. > >> Is it really so unlikely that people >> would make the mistake of assuming they are related? > > Yes.
I also strongly disagree with that. opCmp and opEquals should be separate because only one of them may make sense for a type. But if both make sense they should agree. Of course there exist many possible sorting orders for a type, but the standard comparison operators should always be the natural ones. For other orders you have predicate based sorting. As I understand it, that's also Walters argument why breaking code is ok in that case, because if they don't agree, the code was already buggy in the first place. At very least *I* would be surprised inconsistent comparison operators. And if I wasn't, I still wouldn't implement it like that because I'm sure that someone at some time will be confused by it. Tobi
