<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><div><br></div><div>Dave Abrahams wrote:<br><br></div><blockquote type="cite">Asking whether zero appears in a sequence that happened to contain a NaN would equally be a precondition violation.</blockquote><br><div>No, it wouldn't because Double would implement Equatable + Comparable by providing custom implementations of ==, &lt;, &gt;, &lt;=, and &gt;=, in addition to Double.&lt;=&gt; which may trap.</div><div><br></div><div>My point in&nbsp;<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/025375.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/025375.html</a>&nbsp;is that by keeping all those operators within the required interface of protocol Comparable, such customisation remains possible. The original proposal only suggested == in Equatable and &lt;=&gt; in Comparable. If that were the case, then generic algorithms would necessarily end up calling &lt;=&gt;.</div><div><br></div><div>It is key that not only &lt;=&gt; is a customisation point of Comparable. Only those generic algorithms which used &lt;=&gt; directly (e.g. sort, partition, binary search) would see precondition violations if the sequence contained one or more NaNs.</div><div><br></div><div>***</div><div><br></div><div>Another possible choice would be to return .descending whenever either of the comparands were NaN, while also making &lt;, &gt;, &lt;=, and &gt;= return false in such cases. Then we wouldn't see preconditionFailures but instead produced bogus results from sort, partition etc. That's the tradeoff Haskell has chosen for its `compare` function over Double, FWIW.</div><div><br></div><div>— Pyry</div></div></body></html>