[swift-dev] Rationalizing FloatingPoint conformance to Equatable

[Xiaodi Wu]

On Thu, Nov 2, 2017 at 7:10 PM, Stephen Canon <scanon at apple.com> wrote:

> On Nov 2, 2017, at 7:22 PM, Xiaodi Wu via swift-dev <swift-dev at swift.org>
> wrote:
>
> On Thu, Nov 2, 2017 at 5:22 PM, Matthew Johnson <matthew at anandabits.com>
> wrote:
>
>>
>> On Nov 2, 2017, at 5:20 PM, Jonathan Hull via swift-dev <
>> swift-dev at swift.org> wrote:
>>
>> It looks like we have a good solution.  Per Steve and David’s suggestions:
>>
>> 1) Make FloatingPoint == reflexive
>>
>> 2) Add &== to FloatingPoint for those who specifically want IEEE behavior
>>
>> 3) Add a warning + fixit to ‘a != a’
>>
>> We should take this to evolution…
>>
>>
>> Looks like a winner to me.
>>
>
> Again, there remain several problems with this design. In the concrete
> context, the syntax `&==` suggests that it is a compatibility, legacy, or
> specialized function not to be preferred over `==`. This makes Swift
> deviate from every other programming language, creating a new footgun for
> experienced developers, and encourages a performance hit where one is not
> demonstrably necessary (most operations that ask about UI coordinates, say,
> will never have NaN as an input).
>
>
> This is a real concern, which I don’t think can be dismissed easily. It’s
> really the only major concern that I have, however.
>
> Again also, this design eliminates the possibility of writing a class of
> useful algorithms that use Numeric. It also doesn't address the problem of
> sorting (as NaN would still compare unordered to all other values). These
> are serious questions that require careful consideration.
>
>
> What algorithms do you have in mind? You want to detect and handle NaN for
> a generic algorithm written against Numeric context via x != x, I assume?
>
> If we went down the road that I sketched out, I think we would (completely
> arbitrarily) order NaN after +Inf under Comparable. Anything else would be
> fairly inconsistent.
>

This would break generic numerics terribly. Consider the following:

```
func f<T : Numeric>(_ value: T) {
  if value > 0 {
    // Here, `value` can't be NaN. If NaN > +Inf, this code is now very
broken.
    // What an easy trap to step into, especially since *no other language*
behaves this way.
    // ...
  }
}
```

Likewise, any `precondition(value >= 0)`, etc. For the same reason, it's
not merely about using `x != x` in generic code, although that is one use
case. Consider:

```
func g<T : Numeric>(_ width: T, _ height: T) {
  if width == height {
    // Here, neither `width` nor `height` is NaN.
    // Suppose you're working with bounding boxes.
    // Your code can proceed correctly in manipulating a square bounding
box.
    // If NaN == NaN, this code would be broken. A NaN x NaN shape is not a
square.
  }
}
```

Broadly I agree that if we can find some other way to make things work, we
> should do it, but this also isn’t a *terrible* option.
>
> – Steve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171102/0370a31c/attachment.html>