<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Apr 24, 2016 at 4:51 PM, Brent Royal-Gordon via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> However, I don’t understand how that would help for floating point NaN behavior. Wouldn’t you have to add a fourth member to the enum (“unordered’) that all clients would have to handle? An approach like that could make sense.<br>
<br>
</span>The point is precisely that there *isn't* an `unordered` case. The spaceship operator *must* order all values; that makes it suitable for operations like `sort()` and `max()` which assume there is a total order over all values they encounter. Meanwhile, the traditional comparison operators like `<` and `==` are given flexibility to implement looser semantics like those seen in `FloatingPoint`.<br>
<br>
On the other hand, just because there is *an* order doesn't mean it'll be a *sensible* order. In particular, if `min()` and `max()` are based on an ordering which includes NaNs, then in some circumstances at least one of them will favor a NaN over a normal value. It might be that the total order is not actually a good match for `min()` and `max()`, and they should instead use the partial order and ignore unordered elements.<br>
<br>
(Of course, that again raises the question of whether it is an element or a *pair* of elements which is unordered.)<br>
<br>
Perhaps think of it this way: `<=>` is an *ordering* operator; the others are *comparison* operators. The difference is that, even if two elements cannot be compared, they can still have a consistent order.<br></blockquote><div><br></div><div>I think this is an important distinction to make and perhaps argues against including these changes to Comparable; rather, a separate protocol might be most appropriate. It's important, for instance, that -0.0 and +0.0 compare equal, but also that they be ordered differently. Something else to consider if you insist that all floating point values must be "orderable" would be how two NaNs are ordered if they have different payloads. As far as I'm aware, that goes beyond what IEEE 754 has to say about total ordering of floating point values.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div>