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

Xiaodi Wu xiaodi.wu at gmail.com
Sat Jul 23 13:14:01 CDT 2016

```On Fri, Jul 22, 2016 at 11:34 PM, Stephen Canon <scanon at apple.com> wrote:

> > The point of this design is that `===` means identity and that `.same `
> > also means identity.
> >
> > Since this is new territory I suppose we get to decide what identity
> > means for floating point.  Should +0 and -0 have the same identity or
> > not?  I’ll leave the answer to folks more knowledgable about numerics
> > than I.
>
> Boy, I take my wife out for a movie and come back to 50 new messages on SE.
>
> I need to read the entire thread more carefully, but off the top of my
> head, I think that `-0 === +0` is False.  If we’re going to have an
> `isSame` / `isIdentical` / whatever it's called, I would expect it to imply
> substitutability.  Although -0 == +0, they are not equivalent when
> substituted:
>
> - 1/(-0) != 1/0
> - Float(-0).sign != Float(+0).sign
> - etc
>
> This probably then implies that `<=>` is not `.same` either.  I’ll read
> the rest of this and respond more completely tomorrow.
>

Eagerly await your evaluation of the discussion. In the meantime:

I think Dave's view that `===` defines identity in terms of "essential"
qualities implies that two identical values can be
different/non-substitutable in "inessential" qualities. For generic
purposes, the sign of zero could be one such inessential quality.

On the other hand, the stdlib stride algorithm is going to be borked if -0
< +0. Of course, as we already started to do there, we could specialize for
floating point and then adjust accordingly. However, it seems to me that
every generic algorithm that performs comparisons and can take floating
point arguments would have to be specialized to account for floating point
-0 != +0 (`index(of:)` being the previous example). This appears to defeat
the aim of trying to accommodate FP at all in this revised design for
Comparables.

The argument for `-0 === +0` is that -0 and +0 should be equivalent when
substituted for every comparison operation. For FP operations, you'd
continue to test (as you have to test now) `a == b && a.sign == b.sign` if
you cared about the sign of zero. For non-FP arithmetic operations, hmm,
not sure how to square that circle.

> – Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160723/915c64e3/attachment.html>
```