<div dir="ltr">On Mon, Jul 25, 2016 at 1:12 AM, 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><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On Jul 24, 2016, at 9:06 PM, Pyry Jahkola via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> 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.<br>
<br>
</span>That's essentially what we currently have. I think we'd like to fix it.<br>
<br>
Honestly, I think the most natural result is that calls like `sort()` and `max()` ignore NaNs—for instance, an Array<Double> might have fewer elements if you sort it. That seems to be the behavior implied by `FloatingPoint.maximum/minimum(_:_:)`. However, it is still possible to access and use the total ordering if you need it.<br>
<br>
This sort of suggests we should have two levels of comparisons:<br>
<br>
* `===` and `<===>` are total.<br>
<br>
* `==` and `<=>` may not work on, or may conflate, some values.<br></blockquote><div><br></div><div>Agreed very much. Although, any "friendly" `<=>` can be derived from what you call `<===>` and `==`.</div><div><br></div><div>I've been playing with a variation where I have a "friendly" equivalence relation `==?` (returns `Bool?` so that it's `nil` when there's a argument that doesn't make sense to compare) and a finer equivalence relation `===` as protocol requirements on Equatable, with a generic `==` defined as `{ return (lhs ==? rhs) ?? (lhs === rhs) }`. In that model, traditional comparison operators can be synthesized from a total ordering (which you call `<===>` and the original proposal calls `<=>`) by first consulting the value of the friendly `==?` to determine if two operands are the same.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How to actually accomplish this is a more difficult question. The simplest solution might be something like:<br>
<br>
protocol Equatable {<br>
static func === (…) -> Bool<br>
static func == (…) -> Bool<br>
}<br>
extension Equatable {<br>
static func == (…) -> Bool {<br>
return lhs === rhs<br>
}<br>
}<br>
<br>
protocol Comparable: Equatable {<br>
/// Total ordering which works on and distinguishes between all values of the type.<br>
static func <===> (…) -> Ordering<br>
<br>
/// "Friendly" ordering which may conflate or not work on some values of the type.<br>
///<br>
/// - Precondition: Neither `lhs` nor `rhs` returns `true` from `isAberration`.<br>
static func <=> (…) -> Ordering<br>
<br>
/// If true, this instance should be ignored when using the <=> operator.<br>
var isAberration: Bool { get }<br>
}<br>
extension Comparable {<br>
static func === (…) -> Bool {<br>
return (lhs <===> rhs) == .same<br>
}<br>
static func == (…) -> Bool {<br>
return (lhs <=> rhs) == .same<br>
}<br>
static func <=> (…) -> Ordering {<br>
return lhs <===> rhs<br>
}<br>
var isAberration: Bool {<br>
return true<br>
}<br>
}<br>
<br>
However, this means that sorting requires two functions, not one (or that, when using a custom sorting function, you must separately pre-filter the aberrations from your data set). An alternative would be to introduce a PartialOrdering type:<br>
<br>
<br>
enum PartialOrdering {<br>
case ordered (Ordering)<br>
case leftUnordered<br>
case bothUnordered<br>
case rightUnordered<br>
}<br>
// As above, except...<br>
protocol Comparable: Equatable {<br>
...<br>
<br>
/// "Friendly" ordering which may not work on some values of the type.<br>
///<br>
/// - Precondition: Neither `lhs` nor `rhs` returns `true` from `isAberration`.<br>
static func <=> (…) -> PartialOrdering<br>
}<br>
<br>
This wouldn't necessarily handle the `-0.0 == +0.0` case well, though. That *could* be handled with extra cases meaning "equal but ordered", but this is looking messier and messier.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
</font></span><div class="HOEnZb"><div class="h5"><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>