On 7/23/14, 5:28 PM, Jonathan M Davis wrote:
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.
std.algorithm.sort does not use equality at all. It just deems objects
for which pred(a, b) and pred(b, a) as unordered. -- Andrei
