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