<div dir="ltr">On Sat, Apr 22, 2017 at 7:37 PM, Stephen Canon <span dir="ltr">&lt;<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On Apr 22, 2017, at 6:55 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><div><div 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"><br class="m_-6327397433908549432Apple-interchange-newline">Yes. Specifically, in floating point code. I guess that&#39;s the part about shaping the rug not to cover the bump. IEEE does not require `==` to be the spelling of the quiet equality comparison operator, and it does specifically describe a comparison operator that behaves identically to what I propose as the trapping `==` (which, I believe, is actually spelled in the IEEE standard as `==`).</div></div></blockquote><br></div></span><div>754 does require a `==` that “raises exceptions&quot;, but “raise exception” has a very specific meaning in the 754 standard that does not align up with the Swift notion of “trap&quot;. In particular, “default exception handling” under 754 is to set a sticky flag that may be queried later, not to halt execution. This is exactly what the current Swift `==` operator does at the hardware level on arm64 and x86, though the flags are not accurately modeled by LLVM and there are no Swift bindings for manipulating the floating-point environment [yet] either, so the hardware flag is not especially useful.</div><div><br></div><div>I’m just catching up with this discussion because my daughter was born a couple days ago,</div></div></blockquote><div><br></div><div>First of all, congratulations! Please get sleep instead of catching up on this discussion.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>but my quick reaction to `&amp;==` is that it would make me quite nervous to have `==` not bound to 754-equals as it is in essentially every other language. In particular, I worry about the risk of people porting numerical code that depends on isnan(x) &lt;—&gt; !(x &lt; y) in non-obvious ways that they are unlikely to test. I’ll try to follow up with more detailed thoughts tomorrow.</div></div></blockquote><div><br></div><div>Indeed, it makes me a little nervous too. That said, `==` being either bound or not bound to 754 depending on the context is what makes me even more nervous.</div><div><br></div><div>I was once adamantly against a new spelling for `==`, but on reconsideration it&#39;s clear to me that few if any numerical recipes can be ported verbatim from C-like languages and we should probably not encourage people to do so. Already, `+` needs to be rewritten as `&amp;+`, `&lt;&lt;` probably should be rewritten as `&amp;&lt;&lt;` (I still haven&#39;t had enough time to think about this), and the bitwise operators have differing precedences that require careful proofreading.</div><div><br></div><div>The idea here is to have floating point `&lt;` trap in Swift just like integer `+` traps in Swift. Those who want the &quot;C-like&quot; version would then reach for `&amp;&lt;` and so on, just like they do for integer `+`, bitshifting `&lt;&lt;`, etc.</div><div><br></div><div>Anyway, look forward to your continued thoughts.</div><div><br></div></div></div></div>