On Wed, Oct 25, 2017 at 8:26 PM, Jonathan Hull <[email protected]> wrote:
> > On Oct 25, 2017, at 9:01 AM, David Sweeris via swift-dev < > [email protected]> 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.
_______________________________________________ swift-dev mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-dev
