<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Jul 22, 2016 at 2:52 PM Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
on Fri Jul 22 2016, Tony Allevato <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
<br>
> I like a lot of this, but the changes to Equatable are where I get stuck.<br>
> What are the scenarios where areSame is useful *outside* the context of the<br>
> proposed new Comparable interface?<br>
><br>
> I ask because changing the requirement for Equatable to areSame instead of<br>
> == seems like a backwards change to me. There are plenty of unorderable<br>
> types where == is the obvious thing you want to implement, and this makes<br>
> it less obvious. It also adds a named method to a protocol to serve the<br>
> purpose of an operator, which I've been fighting hard against in SE-0091<br>
> (even though you keep the global one and delegate to it).<br>
><br>
> There are two concepts at play here: comparability and orderability. 99.99%<br>
> of the time, they are identical.<br>
<br>
The concepts are “domain-specific semantics” vs “semantics that is<br>
useful in generic contexts.” Yes, they are usually identical.<br>
<br>
> Your proposal mentions one place where they're not: IEEE floating<br>
> point numbers, because there exists an element in that space, NaN,<br>
> that doesn't satisfy an equivalence relation at all.<br>
<br>
It's not limited to NaN. The +0/-0 distinction can be tricky as well.<br>
<br>
> But it's still reasonable to want a stable ordering with those<br>
> included.<br>
<br>
It's also reasonable to want to search for those in a collection or use<br>
them as hash keys. I'm pointing this out because it goes to the<br>
definition of equality, which sorting in general does not.<br>
<br>
> In the proposal as it's written right now, the individual inequality<br>
> operators are implemented in terms of <=>. That won't work for<br>
> FloatingPoint, because (NaN < x) and (NaN >= x) should both be false but<br>
> the default implementations provided would make the latter true. So<br>
> FloatingPoint would still have to provide its own implementations of *all<br>
> of the (in)equality operators*, not just ==, in order to have the correct<br>
> definition w.r.t. to IEEE 754. I didn't see that called out anywhere in the<br>
> write-up.<br>
<br>
That's my error, actually. I wasn't thinking straight when I proposed a<br>
change to the proposal that I claimed dropped the need for the other<br>
operators.<br>
<br>
> That being said, don't get me wrong—there's still a lot about this proposal<br>
> that I like :) Here's what I'm thinking (which is mostly what you have<br>
> written, with some tweaks):<br>
><br>
> 1) Don't change Equatable. I don't see a need to distinguish between<br>
> equivalence and equality on its own (if there is one, please let me<br>
> know!).<br>
<br>
There is, because for algorithms that require Equatable to have any kind<br>
of meaningful semantics the equivalence relation requirement must be<br>
fulfilled, and prominent types exist whose `==` operator is not an<br>
equivalence relation.<br></blockquote><div><br></div><div>Thanks for the detailed reply, Dave—this and some of your earlier replies to this thread have helped me understand the use cases for this distinction. So the argument is that something like this:</div><div><br></div><div> [ 1.0, -2.0, Double.NaN, 4.0 ].contains(Double.NaN)</div><div><br></div><div>should return true because the argument is in the same equivalence class as the element, even though NaN == NaN currently returns false? That seems totally reasonable, and I think i<span style="line-height:1.5">t would be very helpful for the proposal to specifically call out some of these scenarios—right now it focuses mostly on ordering, which led to my confusion.</span></div><div><br></div><div>To take this further, let's say I have a data structure where the elements are a type with multiple fields, and the ordering is determined by a single one of those fields (the "key"). Would a reasonable definition of equivalence in this model be one where a is equivalent to b if a.key == b.key, regardless of the values of the other fields, and equality is implemented by comparing all the fields? This is similar to how C++ STL's definition of equivalence for ordered collections falls out of the expression !(a < b) && !(b < a), since you could conceivably implement < and == with the same distinctions there.</div><div><br></div><div>I would be completely supportive of using `===` for this equivalence instead of areSame, based on your argument about identity. Would we need an escape hatch for people who absolutely need to know whether two instances occupy the same address? If I had to choose equivalence vs. same-address as the one to make more verbose, same-address seems like the obvious choice to me.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> As it stands today, I think the proposal "leaks" ordering concepts into<br>
> Equatable when it shouldn't.<br>
<br>
I don't see any evidence for that, and I don't even believe you've said<br>
anything here to support that point of view.<br>
<br>
> 2) Comparable defines <=>, as proposed, but *also* defines <, >, <=, >=. A<br>
> protocol extension provides defaults for <, >, <=, >=, ==, and !=<br>
> implemented in terms of <=>. This lets most implementors of Comparable<br>
> implement <=> and get everything else for free, but it also lets types<br>
> replace individual operators with customized implementations (see #4 below)<br>
> easily *within* the type (SE-0091).<br>
<br>
Check<br>
<br>
> 3) Comparable should be documented to imply that the default behavior is to<br>
> link the behavior of <=> to the individual comparisons, but that it can be<br>
> changed, meaning that only <=> must define a total ordering and the<br>
> individual comparison operators need not.<br>
<br>
Yes, the doc comments are missing from the proposal.<br>
<br>
> 4) The very few types, like FloatingPoint, that need to provide<br>
> domain-specific behavior to do the obvious/intended thing for users can and<br>
> should override <, >, <=, >=, ==, and !=. This should be called out<br>
> explicitly, and it would *not* affect ordering.<br>
<br>
Depends what you mean by “affect ordering.” Clearly if you sort Floats<br>
using < explicitly, it will have an effect.<br>
<br>
> I think it's entirely reasonable to have (NaN == NaN) return false and<br>
> (NaN != NaN) return true but (NaN <=> NaN) return .same without<br>
> introducing another areSame concept, because the former is demanded by<br>
> IEEE 754. 5) Algorithms that rely on a total order, like sorts, must<br>
> be implemented in terms of <=>, not in terms of the individual<br>
> operators, because of the possibility that the definitions can be<br>
> severed above.<br>
<br>
But you're forgetting algorithms that require an equivalence relation,<br>
which is basically everything that's constrained to Equatable.<br>
<br>
> As mentioned below, the one thing that a three-way comparison loses is the<br>
> easy ability to pass > instead of < to reverse the ordering, but it's<br>
> trivial to write a function that does this and I think it should be<br>
> included as part of the proposal. Something like this (may be typos, I'm<br>
> writing it in Gmail):<br>
><br>
> public func reverse<C: Comparable>(ordering: (C, C) -> Ordering) -> (C, C)<br>
> -> Ordering {<br>
> return { lhs, rhs in<br>
> switch ordering(lhs, rhs) {<br>
> case .ascending: return .descending<br>
> case .descending: return .ascending<br>
> case .same: return .same<br>
> }<br>
> }<br>
><br>
> (Comedy alternative: Add a second operator, >=<. But that might be pushing<br>
> it.)<br>
<br>
Agreed, we should do something about this use case.<br>
<br>
--<br>
Dave<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">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>
</blockquote></div></div>