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

[Karl]

> On 22 Jul 2016, at 16:54, Matthew Johnson <matthew at anandabits.com> wrote:
> 
>> 
>> On Jul 22, 2016, at 9:48 AM, Karl via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> On 22 Jul 2016, at 03:32, Robert Widmann via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>>> On Jul 21, 2016, at 6:19 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>>>> 
>>>> This is nice. Is `areSame()` being proposed because static `==` is the status quo and you're trying to make the point that `==` in the future need not guarantee the same semantics?
>>> 
>>> Yep!  Equivalence and equality are strictly very different things.
>>> 
>> 
>> As I understand it:
>> 
>> -> what we call “Equatable” today checks for equivalence. For value types, equivalent is the same as equality (that’s why they are values - two instances with the same data are indistinguishable).
>> -> For reference types, we have an instance-equality operator (===) which checks for what I believe you mean by equality.
> 
> Except that the standard floating point == is not an equivalence relation.  I’m not sure if the distinction introduced by this proposal is solely due to that or if there are other example use cases for making a distinction.
> 
>> 
>> Karl
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
If it is literally just that one FloatingPoint case, then should decide which FloatingPoint should offer as the default and offer the alternative implementation as a method on FloatingPoint (areIEEEEqual()? :P areEqualOrBothNan()?).

The additional benefit is that this secondary equivalence function is far more descriptive about what it is doing. I’m not sure you will really be able to write generic code which always knows whether (==/areSame) are appropriate, because the differences would be so subtle. You would really have to check on a type-by-type basis.

e.g.

func find<T>(_ value: T, in arr: Array<T>) -> Array<T>.Index? {

    if T is FloatingPoint {
       return (arr as! Array<FloatingPoint>).index(where: { $0.areEqualOrBothNan(value) })
    }
    else {
        return arr.index(where: { $0 == value })
    }
}

Or something better without casting and with overloads for generic constraints…

Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160722/edf2190b/attachment.html>