[swift-dev] Rationalizing FloatingPoint conformance to Equatable
xiaodi.wu at gmail.com
Wed Oct 25 20:36:01 CDT 2017
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...
More information about the swift-dev