<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 22, 2017, at 6:55 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><div class=""><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; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">Yes. Specifically, in floating point code. I guess that'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 class=""></div><div>754 does require a `==` that “raises exceptions", but “raise exception” has a very specific meaning in the 754 standard that does not align up with the Swift notion of “trap". 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 class=""></div><div>I’m just catching up with this discussion because my daughter was born a couple days ago, but my quick reaction to `&==` 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) <—> !(x < y) in non-obvious ways that they are unlikely to test. I’ll try to follow up with more detailed thoughts tomorrow.</div><div><br class=""></div><div>– Steve</div></body></html>