> On Apr 22, 2017, at 6:55 PM, Xiaodi Wu <xiaodi...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
