On Thursday, 24 July 2014 at 00:28:06 UTC, 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.
- Jonathan M Davis
floating point ?
