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

[Nevin Brackett-Rozinsky]

Excellent point Karl.

In my view, floating point NaN values are really quite similar to `.none`.

I would be interested in exploring a move *away* from the IEEE 754 handling
of NaN. In particular, we could model Float and Double as optionals (maybe
implicitly-unwrapped) with NaN bit-patterns indicating `.none`.

Or we could model *just the non-NaN values* and make undefined operations
trap, among other possibilities.


5. Will it be considered "ok" to define a type for which `T.areSame(a, b)
>> == true` but `a != b`? An obvious example would be Double.nan, so I assume
>> the answer is a resounding yes.
>
>

Yes, because `==` is not a protocol requirement of Equatable, so it
> can have domain-specific semantics.


Per SE-0091
<https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md>
the
operator will be the protocol requirement.

Nevin


On Fri, Jul 22, 2016 at 11:06 AM, Karl via swift-evolution <
swift-evolution at swift.org> wrote:

>
> 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> wrote:
>
>
> On 22 Jul 2016, at 03:32, Robert Widmann via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Jul 21, 2016, at 6:19 PM, Xiaodi Wu <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
> 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160722/eab52887/attachment.html>