> On Oct 25, 2017, at 9:01 AM, David Sweeris via swift-dev > <swift-dev@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. Thanks, Jon _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
