[swift-evolution] [pitch] Comparison Reform

[Stephen Canon]

> On Apr 22, 2017, at 6:55 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> 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 `==`).

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.

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.

– Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170422/88607009/attachment.html>