[swift-dev] Rationalizing FloatingPoint conformance to Equatable

[Jonathan Hull]

One completely different idea, which I brought up a year or so ago, is to do what we do with pointers around this.  That is you have your fast/unsafe IEEE Floats/Doubles/etc that have a scarier name.  These do not conform to Equatable or Comparable, but have their own version of IEEE equality/comparison. Let’s spell it &== and &< to make it feel different so the users consider the possibility of NaN.  They don’t have any notion of hashability.

Then you have your safe/friendly Swift Floating point type(s) which just have no concept of NaN at all (and probably a single notion of zero). You have a failable initializer from the IEEE versions. These types conform to Equatable/Hashable/Comparable.  Care is taken with internal methods so that NaN can’t creep into the type.  

How do we handle math functions which might fail?  We do the same thing we do in the rest of Swift... those functions return an optional.

When reading in data from the outside world or C code, you would use the IEEE versions and then either convert or do your calculations directly.  They would probably also be used for things like accelerate.  But most code, where the values come from user input or literals, would never even have to touch the IEEE version.

The advantage here is that you get full speed all the time, even in generic contexts.  You just can’t use the IEEE versions directly in generic contexts. You would have to convert them, which is a one-time cost (or use them non-generically).

Thanks,
Jon