[swift-dev] Rationalizing FloatingPoint conformance to Equatable

[Xiaodi Wu]

On Wed, Oct 25, 2017 at 8:26 PM, Jonathan Hull <jhull at gbis.com> wrote:

> > On Oct 25, 2017, at 9:01 AM, David Sweeris via swift-dev <
> swift-dev at swift.org> wrote:
> >
> > That said, I fully acknowledge that this is all above my pay grade (also
> I hadn't realized that the issue was as settled as it apparently is). If
> splitting the protocols is a no-go from the get go, I'll go back to trying
> to figure out a better way to handle it without doing that.
>
>
> I don’t think it is settled.  The issue that Xiaodi mentioned was a
> PartiallyEq protocol which still had a signature of (T,T)->Bool.  People
> just used that protocol instead of Equatable without taking into account
> the difference in behavior.  The signature of (T,T)->Bool? changes things
> because people are forced to deal with the optional.
>
> Currently, I think we should do 3 things:
>
> 1) Create a new protocol with a partial equivalence relation with
> signature of (T, T)->Bool? and automatically conform Equatable things to it
> 2) Depreciate Float, etc’s… Equatable conformance with a warning that it
> will eventually be removed (and conform Float, etc… to the partial
> equivalence protocol)
> 3) Provide an '&==‘ relation on Float, etc… (without a protocol) with the
> native Float IEEE comparison
>
> I think this provides several benefits.  #3 allows pure speed when needed,
> but not in a generic context (and is appropriately scary to cause some
> thought).  #1 forces correct handling in generic contexts.  #2 gives people
> time to make the adjustment, but also eventually requires them to switch to
> using #1 or #3.
>
> I think it will cause A LOT of currently incorrect code to be fixed.
>

One issue which occurred to me only recently, which I hadn't considered,
renders my `&==` idea and all similar schemes untenable:

Useful algorithms can and are written which operate on both floating-point
and integer numeric types. In fact, the whole point of laboriously
designing `Numeric` as part of SE-0104 was to make it possible to do so. If
IEEE comparison is relegated to `FloatingPoint` and the only operator
remaining on `Numeric` is `==`, then not only will there be a mandatory
performance hit, but currently correct algorithms can be broken with
absolutely no way to express a fix.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171025/97c9898d/attachment.html>