[swift-evolution] [pitch] Comparison Reform

[Xiaodi Wu]

On Wed, Apr 26, 2017 at 2:14 PM, Michel Fortin via swift-evolution <
swift-evolution at swift.org> wrote:

> Just throwing a idea that came to me while reading this discussion
> (hopefully not duplicating something that was already suggested)...
>
> We could introduce `FiniteFloat` and `FiniteDouble` types that would
> disallow NaN and infinity. Computations creating NaN or infinity would trap
> with these types, mimicking what happens with integers in Swift. Converting
> a `Double` to `FiniteDouble` would be achieved through a `finiteValue`
> property like this:
>
>         var a = 1.0
>         var b = a.finiteValue!
>
> where the `finiteValue` property returns a `FiniteDouble?` that is `nil`
> for NaN or infinity values. The finite type variant can conform to
> Equatable with no issue. The regular one that allows NaNs and infinity
> would then have less pressure to conform to Equatable. Just request the
> finite value whenever you need it:
>
>         dict[a.finiteValue!] = "a"
>
> I understand that this goes a bit beyond solving the problem with
> comparison which is caused by NaNs and not by infinity values. But it's
> quite easy to explain what "finite" means and it follows how integers
> works. It also has the interesting property of guarantying a finite value
> for APIs that needs that, which I believe is more frequent than APIs that
> require only a non-NaN value. Hence why I'm suggesting FiniteDouble and not
> NonNaNDouble.
>

The issue, here, again is that you're proposing tinkering with Swift
floating point types without addressing the motivations here, which is an
issue with _Comparable_. The problem is that:

(a) People use arrays of type Float and Double.

(b) You can invent new ways to represent floating point values, but as long
as you interact with data from anywhere else (not just interoperating with
C or using existing algorithms that make use of floating point types, but
even simply reading in any file that stores floating point data, since
those will be serialized as IEEE floating point values), you _will_ be
using Float and Double.

(c) People expect to sort and compare arrays of type Float and Double.

You can introduce a type called DefinitelyNotNaNDouble and then rename
Double to PotentiallyReallyBadNaNDouble, but people will still need to sort
and compare arrays of PotentiallyReallyBadNaNDouble. And after all that
work, you still have not answered the question, how do we write generic
algorithms that (a) use generic comparison; and (b) behave in a sensible
way when working with values of type PotentiallyReallyBadNaNDouble?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170426/4c28d8e4/attachment.html>