4 ms·

The default operators are very cool, but I assume that many codebases would ban them. Imagine, for example, an engineer decided to reorder members in a struct

The default operators are very cool, but I assume that many codebases would ban them. Imagine, for example, an engineer decided to reorder members in a struct to make it pack better. Now the semantics of default <=> have changed! Also, as a minor nit, the optional number sample has a possible bug. I would assume that two null optionals would compare equivalently. Or is that part of how <=> should work? Should NaN <=> NaN == partial_ordering::unordered?

maxwellburson 7y ago
While I don't know about this specific case, I do know in some languages, like JavaScript, NaN poisons any operation it is part of. So any operation on it is NaN, and comparisons to it are false.
- magicalhippo 7y ago
  This is default IEEE 754 behavior. https://en.wikipedia.org/wiki/NaN https://en.wikipedia.org/wiki/NaN
yablak 7y ago
Yes, the standard and expected behavior is that logical_op(NaN, anything) == false [except inequality] because NaN is not ordered with, or equal to, anything, including another NaN. Otherwise you may have the strange behavior that two erroneous values are equal, e.g., 0*inf == tan(inf).
jcranmer 7y ago
I don't have the IEEE 754 specification in front of me to verify, but the usual descriptions of floating point comparison considers it to be a 4-value (<, =, >, unordered), with 16 different operators defining for which of those values the comparison returns true. So an ordered equals returns true only when the result is =, but an unordered equals returns true if the result is = or unordered. The unordered operation is returned if either operand is unordered, which makes the comparison non-reflexive. Note that floating point is already weird, because most languages make == reflect the ordered equals, not the unordered equals, and so the primitive equality for floats violates the reflexive principle (i.e., x == x returns false).
contravariant 7y ago
I reckon that having a single operator would make it easier to pass through a custom comparer to whatever function you need. That is probably a better option than changing the default <=> of a type. For what it's worth the mathematical definition of partial orders suggests having NaN equivalent to NaN. You're not really forced to but giving up reflexivity doesn't seem worth it (unless you want to view each NaN a it's own object). Interestingly mathematics only defines <= for a specific kind of object. Although on it's own this doesn't give you much information about what kind of relation it is.

maxwellburson 7y ago

While I don't know about this specific case, I do know in some languages, like JavaScript, NaN poisons any operation it is part of. So any operation on it is NaN, and comparisons to it are false.

magicalhippo 7y ago
This is default IEEE 754 behavior. https://en.wikipedia.org/wiki/NaN https://en.wikipedia.org/wiki/NaN

yablak 7y ago

Yes, the standard and expected behavior is that logical_op(NaN, anything) == false [except inequality] because NaN is not ordered with, or equal to, anything, including another NaN. Otherwise you may have the strange behavior that two erroneous values are equal, e.g., 0*inf == tan(inf).

jcranmer 7y ago

I don't have the IEEE 754 specification in front of me to verify, but the usual descriptions of floating point comparison considers it to be a 4-value (<, =, >, unordered), with 16 different operators defining for which of those values the comparison returns true. So an ordered equals returns true only when the result is =, but an unordered equals returns true if the result is = or unordered. The unordered operation is returned if either operand is unordered, which makes the comparison non-reflexive. Note that floating point is already weird, because most languages make == reflect the ordered equals, not the unordered equals, and so the primitive equality for floats violates the reflexive principle (i.e., x == x returns false).

contravariant 7y ago

I reckon that having a single operator would make it easier to pass through a custom comparer to whatever function you need. That is probably a better option than changing the default <=> of a type. For what it's worth the mathematical definition of partial orders suggests having NaN equivalent to NaN. You're not really forced to but giving up reflexivity doesn't seem worth it (unless you want to view each NaN a it's own object). Interestingly mathematics only defines <= for a specific kind of object. Although on it's own this doesn't give you much information about what kind of relation it is.