> On Apr 16, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution
> <[email protected]> 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...
Thanks,
Jon
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
