[swift-dev] Rationalizing FloatingPoint conformance to Equatable

[Ben Cohen]

> On Oct 31, 2017, at 10:11 PM, Chris Lattner via swift-dev <swift-dev at swift.org> wrote:
> 
> On Oct 31, 2017, at 9:07 AM, Stephen Canon via swift-dev <swift-dev at swift.org> wrote:
>> [Replying to the thread as a whole]
>> 
>> There have been a bunch of suggestions for variants of `==` that either trap on NaN or return `Bool?`. I think that these suggestions result from people getting tunnel-vision on the idea of “make FloatingPoint equality satisfy desired axioms of Equatable / Comparable”. This is misguided. Our goal is (should be) to make a language usable by developers; satisfying axioms is only useful in as much as they serve that goal.
>> 
>> Trapping or returning `Bool?` does not make it easier to write correct concrete code, and it does not enable writing generic algorithms that operate on Comparable or Equatable. Those are the problems to be solved.
> 
> +100.  Swift isn’t the first language to face the problems of floating point, nor is it the first to try to shoehorn it into a framework like Equatable.  

Java and C# do not have this problem with their generic algorithms (albeit possibly because of limitations in their languages that Swift doesn’t have). Swift is setting itself up as a major language with confusing and unjustifiable behavior by comparison. That some other languages are also bad at this doesn’t seem relevant.

> Despite weird cases involving NaNs, I haven’t seen a significant example of harm that it causes in practice,

Sorting an array with NaNs resulting in arbitrary ordering, weird edge cases like == behaving differently depending on the identity of the buffer, don’t seem like problems in practice? Users do encounter these problems, that’s what led to this discussion.

> nor have I seen a proposal that makes the state of the art *better* than it currently is.  

I agree trapping and optional bool solutions aren’t good.

Steve’s preferred approach later in the email  – that NaN == NaN and that &== be used for IEEE when needed – seems significantly better than the current situation. I hadn’t thought this was on the table, hence the more elaborate suggestions about generic vs concrete contexts. But if this is acceptable in the eyes of at least some FP experts, that’s certainly the best option from my perspective.

> IMO, better involves reducing existing pain without introducing new pains that are more significant than the old ones.
> 
> -Chris
> 
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev