[swift-evolution] [pitch] Comparison Reform

[Dave Abrahams]

on Sun Apr 16 2017, Xiaodi Wu <swift-evolution at swift.org> wrote:

> On Sun, Apr 16, 2017 at 1:14 PM, Jonathan Hull <jhull at gbis.com> wrote:
>
>>
>> On Apr 16, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> The point is that, when you manipulate two real numbers, sometimes there
>> is no numeric result. You cannot simply wish this away with a new numeric
>> type because it is not an artifact of _modeling_ real numbers but rather
>> intrinsic to mathematics itself.
>>
>>
>> I agree with the rest of what you said, but I have to disagree on this
>> point.  What I think he is saying is that, in Swift, we really should be
>> representing the NaN case as an optional instead of a magic value on the
>> type itself (similar to how swift uses an optional instead of NSNotFound).
>>
>> In fact, that might be an actual option here.  For ‘Double?’ the compiler
>> could use the bit pattern for NaN internally to represent .none (I believe
>> it does similar tricks to save space with other optional types).  Then
>> disallow reference to NaN within swift code.  Functions or operations which
>> could produce NaN would either have to produce an optional or trap in case
>> of NaN. (e.g. the trig functions would likely return an optional, and 0/0
>> would trap).
>>
>> I think it would actually lead to much better code because the compiler
>> would force you to have to explicitly deal with the case of optional/NaN
>> when it is possible.  Migration would be tricky though...
>>
>
> This is essentially a cosmetic renaming from `Double` to `Double?`. There
> are rules for propagating NaN which numeric algorithms expect. For example,
> `cos(.nan)` returns a value. If your design is to work, every function that
> takes a `Double` will need to take a `Double?`.
>
> Just as Swift String conforms to Unicode standards, FloatingPoint conforms
> to IEEE standards. You'd have to come up with enormous benefits to justify
> breaking that. Doing so for Swift 4 is plainly a non-starter.

+1

-- 
-Dave