<div dir="ltr">On Fri, Jul 22, 2016 at 2:26 PM, Pyry Jahkola 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">I agree with Tony that we should still keep == and != as part of Equatable, and<, <=, >, and >= as part of Comparable, while offering default implementations through <=>.<br>
<br>
The reason is, that otherwise generic code would dispatch differently depending on the generic constraint; <T : Comparable> would only see the operators using <=> while <T : FloatingPoint> would pick up the IEEE-754 versions, even if in both cases T were Double.<br>
<br>
Below is a concrete example where things wouldn't work as expected, given the proposal omitting the other operators in the protocols:<br>
<span class=""><br>
Dave Abrahams wrote:<br>
<br>
>> In order to have an opinion on whether or not this is justified, I<br>
>> need to know more about how areSame() may differ from == and how this<br>
>> will affect generic code. What is required that could not fit inside<br>
>> an override of Equatable?<br>
><br>
> Floating point types. You should be able to ask for<br>
> arrayOfFloats.firstIndex(of: x) even if there are NaNs in the array (or<br>
> x).<br>
<br>
</span>Given that func firstIndex<T : Equatable>(of value: T) dispatches on Equatable, it would use Double.areSame(_:_:) instead of the IEEE-754 Double.==(_:_:). While that sounds innocuous, it would cause surprising results in the presense of negative zero:<br>
<br>
[-0.0, 1.0, .nan, 0.0].firstIndex(of: 0.0)<br>
//=> 3, not 0<br></blockquote><div><br></div><div>I just assumed that the core team's vision was that this would be addressed by a domain-specific floating point `areSame(a: Self, b: Self) -> Bool { return (a == 0 && b == 0) || (a <=> b) == .same }`. This is a valid equivalence relation afaik.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
which almost definitely isn't what the caller would want. Instead, functions like these should clearly document (or it should be obvious from their semantics) whether they use == and < (etc), or <=> in their implementation. I think that is a reasonable price to pay.<br>
<br>
Or am I missing something obvious about round pegs and square holes?<br>
<br>
— Pyry<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<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>