Am 24.07.2014 01:52, schrieb Andrei Alexandrescu:
I'm unconvinced. Most algorithms that need inequality don't need
equality comparison; instead, they consider objects for which both !(a <
b) && !(b < a) in the same "equivalence class" that doesn't assume they
are actually equal.
Bottom line, inferring opEquals from opCmp seems fishy.
You're thinking too algorithm-centric :-P
When I implement the "comparison operator" for my type, I expect it to
be used for comparisons - and that includes equality.
If I had the feeling that I could implement == in a more efficient way,
or that I actually want equality to have different semantics, I'd just
implement opEquals as well.
IMHO, everything else would be just confusing to the "average" user, and
if someone wants to be confused by counterintuitive rules (however much
sense they may make in some way) he could as well just use C++ instead.
But if the general view really is that opEquals should *not* be opCmp ==
0 by default, for performance reasons or whatever, then please enforce
defining opEquals when opCmd is defined, so it's at least explicit that
opCmd does not define equality.
Cheers,
Daniel
