[swift-dev] Rationalizing FloatingPoint conformance to Equatable

Jonathan Hull jhull at gbis.com
Wed Oct 25 20:26:14 CDT 2017

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


More information about the swift-dev mailing list