[swift-evolution] [pitch] Comparison Reform

[Xiaodi Wu]

On Sat, Apr 22, 2017 at 7:37 PM, Stephen Canon <scanon at apple.com> wrote:

>
> 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,
>

First of all, congratulations! Please get sleep instead of catching up on
this discussion.

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.
>

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.

I was once adamantly against a new spelling for `==`, but on
reconsideration it'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 `&+`, `<<` probably
should be rewritten as `&<<` (I still haven't had enough time to think
about this), and the bitwise operators have differing precedences that
require careful proofreading.

The idea here is to have floating point `<` trap in Swift just like integer
`+` traps in Swift. Those who want the "C-like" version would then reach
for `&<` and so on, just like they do for integer `+`, bitshifting `<<`,
etc.

Anyway, look forward to your continued thoughts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170422/926f96c6/attachment.html>