On Thu, Nov 2, 2017 at 7:10 PM, Stephen Canon <sca...@apple.com> wrote:
> On Nov 2, 2017, at 7:22 PM, Xiaodi Wu via swift-dev <swift-dev@swift.org>
> wrote:
>
> On Thu, Nov 2, 2017 at 5:22 PM, Matthew Johnson <matt...@anandabits.com>
> wrote:
>
>>
>> On Nov 2, 2017, at 5:20 PM, Jonathan Hull via swift-dev <
>> swift-dev@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
>
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
