On Thursday, 24 July 2014 at 01:37:01 UTC, deadalnix wrote:
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 ?
When it comes to equality and comparison, floating point values
are mess that I would really hope no one would be looking to
emulate with their own types. I grant you that they're a built in
type, but they do not have clean semantics (particularly with
regards to equality). IMHO, user-defined types should emulate
integers with regards to how the comparison operators work.
Allowing more nonsense like what FP does does not improve things.
- Jonathan M Davis
