<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 ==, <, >, <=, and >=, in addition to Double.<=> which may trap.</div><div><br></div><div>My point in <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> 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 <=> in Comparable. If that were the case, then generic algorithms would necessarily end up calling <=>.</div><div><br></div><div>It is key that not only <=> is a customisation point of Comparable. Only those generic algorithms which used <=> 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 <, >, <=, and >= 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>