On Wednesday, 23 July 2014 at 21:36:16 UTC, Andrei Alexandrescu
wrote:
On 7/23/14, 12:04 PM, H. S. Teoh via Digitalmars-d wrote:
If autogenerating opEquals to be opCmp()==0 is a no-go, then
I'd much
rather say it should be a compile error if the user defines
opCmp but
not opEquals.
No. There is this notion of partial ordering that makes objects
not smaller and not greater than others, yet not equal. --
I would strongly argue that if lhs.opCmp(rhs) == 0 is not
equivalent to lhs == rhs, then it that type is broken and should
not be using opCmp to do its comparisons. std.algorithm.sort
allows you to use any predicate you want, allowing for such
orderings, but it does not work with generic code for a type to
define opCmp or opEquals such that they're not consistent,
because that's not consistent with how comparisons work for the
built-in types.
- Jonathan M Davis
