<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">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt; 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&#39;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 `&lt;` 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&#39;t mean it&#39;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: `&lt;=&gt;` 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&#39;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 &quot;orderable&quot; would be how two NaNs are ordered if they have different payloads. As far as I&#39;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>