[swift-dev] Rationalizing FloatingPoint conformance to Equatable

[Jonathan Hull]

> On Nov 2, 2017, at 5:10 PM, Stephen Canon via swift-dev <swift-dev at swift.org> wrote:
> 
> On Nov 2, 2017, at 7:22 PM, Xiaodi Wu via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
> 
>> On Thu, Nov 2, 2017 at 5:22 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>> 
>>> On Nov 2, 2017, at 5:20 PM, Jonathan Hull via swift-dev <swift-dev at swift.org <mailto: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.

If performance is a big concern, I think we can reclaim it in many common use cases with just a little help from the compiler.  Basically, if there are cases that can be guaranteed not to have NaN (e.g. a literal), then we can just use the machine instruction.

Also, we could consider moving &== from FloatingPoint to Numeric. 

Thanks,
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171104/8af0dcce/attachment.html>