[swift-evolution] [Draft][Proposal] Formalized Ordering

[Dave Abrahams]

on Fri Jul 22 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:

> On Fri, Jul 22, 2016 at 2:26 PM, Pyry Jahkola via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> 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 <=>.
>>
>> 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.
>>
>> Below is a concrete example where things wouldn't work as expected, given
>> the proposal omitting the other operators in the protocols:
>>
>> Dave Abrahams wrote:
>>
>> >> In order to have an opinion on whether or not this is justified, I
>> >> need to know more about how areSame() may differ from == and how this
>> >> will affect generic code. What is required that could not fit inside
>> >> an override of Equatable?
>> >
>> > Floating point types.  You should be able to ask for
>> > arrayOfFloats.firstIndex(of: x) even if there are NaNs in the array (or
>> > x).
>>
>> 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:
>>
>>     [-0.0, 1.0, .nan, 0.0].firstIndex(of: 0.0)
>>     //=> 3, not 0
>>
>
> 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.

IEEE-754 specifies a standard equivalence relation that we'd use for
this.

>> 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.
>>
>> Or am I missing something obvious about round pegs and square holes?
>>
>> — Pyry
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>

-- 
Dave