<div dir="ltr"><div>On Tue, Apr 25, 2017 at 6:53 PM, Jonathan Hull <span dir="ltr">&lt;<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>&gt;</span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">I just wanted to ask for more detail on why this is a non-starter (it seems like most of my ideas are dismissed as “non-starters”, but I am rarely given a detailed reason why).<div><br></div><div>Migration would be a renaming from ‘Double&#39; to ‘Double?’, but it wouldn’t be cosmetic.  It would free us to use a non-optional Double, where we can guarantee the answer wouldn’t be NaN/nil.  We would, as you say, have functions like ‘cos(Double?)-&gt;Double?’ which propagate the optional, but we could also add a ‘cos(Double)-&gt;Double’ overload which guarantees an actual result.  For something like Tan, we would only have the optional version because the answer may actually be undefined, even when the input isn&#39;t.</div></div></blockquote><div><br></div><div>Leave aside how one might implement such a system for a moment. The first major issue is that your idea does not address the issues we&#39;re talking about here:</div><div><br></div><div>We are debating, for instance, how to compare arrays with elements of type `Double`. In your design, the question remains how we would compare arrays with elements of type `Double?`. If the answer is that you cannot compare arrays of type `[Double?]`, then we have a problem, because that&#39;s the type that people will use when they ingest data that might contain NaN. Sure, they can unwrap each element before using their data, but they can also test each element with `isNaN` today. We are trying to *improve* on the user experience of comparing arrays of floating point values *without* checking if they contain NaN, not trying to take that feature away.</div><div><br></div><div>Your design also doesn&#39;t address the problem of how NaN should compare with NaN. Only now, you&#39;ve pushed the problem to `Optional`. By design, every `Optional&lt;T&gt;.none` compares equal to every other `Optional&lt;U&gt;.none` (yes, even of different types). This did not always work correctly, if I recall, but it does now and it&#39;s an intentional part of the design. However, NaN must compare not equal to every NaN. These could not be more different properties. It seems quite absurd on its face that we might want NaN to compare equal to a value of type `Optional&lt;UIViewController&gt;`.<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>In short, it would actually make people consider conditions which result in NaN because of Swift’s machinery which makes people consider nil.</div><div><br></div><div>It also allows non-optional Double to easily conform to Comparable, and removes the gotchas around Collections…  Pretty big wins for a “cosmetic rename”.  The only thing we lose is &#39;NaN != Nan&#39; (because nil == nil), but then algorithms that had relied on that would be forced to consider the NaN/nil case explicitly because of the optionals.</div><div><br></div><div>It would also inter-op well with C/ObjC code by just having the compiler overlay Double? for Double…</div><div><br></div><div>Thanks,</div><div>Jon</div><div><br></div><div><br><div><blockquote type="cite"><div>On Apr 16, 2017, at 11:44 AM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br class="gmail-m_-2105822621181210603gmail-m_6947921313014429943Apple-interchange-newline"><div><div dir="ltr" style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Sun, Apr 16, 2017 at 1:14 PM, Jonathan Hull<span class="gmail-m_-2105822621181210603gmail-m_6947921313014429943Apple-converted-space"> </span><span dir="ltr">&lt;<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>&gt;</span><span class="gmail-m_-2105822621181210603gmail-m_6947921313014429943Apple-converted-space"> </span>wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span><br><div><blockquote type="cite"><div>On Apr 16, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="gmail-m_-2105822621181210603gmail-m_6947921313014429943m_5034690051034842618Apple-interchange-newline"><div><span style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">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.</span></div></blockquote></div><br></span><div>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).</div><div><br></div><div>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).</div><div><br></div><div>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...</div></div></blockquote><div><br></div><div>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?`.</div><div><br></div><div>Just as Swift String conforms to Unicode standards, FloatingPoint conforms to IEEE standards. You&#39;d have to come up with enormous benefits to justify breaking that. Doing so for Swift 4 is plainly a non-starter.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>Thanks,</div><div>Jon</div></div></blockquote></div></div></div></div></blockquote></div><br></div></div></blockquote></div><br></div></div>