> On Apr 18, 2017, at 1:34 AM, Gwendal Roué <gwendal.r...@gmail.com> wrote: > >> >> Le 18 avr. 2017 à 06:45, Joe Groff via swift-evolution >> <swift-evolution@swift.org> a écrit : >> >>> >>> On Apr 17, 2017, at 9:40 PM, Chris Lattner <clatt...@nondot.org> wrote: >>> >>> >>>> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> >>>>> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution >>>>> <swift-evolution@swift.org> wrote: >>>>> >>>>> For example, I expect `XCTAssertEqual<T : FloatingPoint>(_:_:)` to be >>>>> vended as part of XCTest, in order to make sure that >>>>> `XCTAssertEqual(resultOfComputation, Double.nan)` always fails. >>>> >>>> Unit tests strike me as an example of where you really *don't* want level >>>> 1 comparison semantics. If I'm testing the output of an FP operation, I >>>> want to be able to test that it produces nan when I expect it to, or that >>>> it produces the right zero. >>> >>> I find it very concerning that == will have different results based on >>> concrete vs generic type parameters. This can only lead to significant >>> confusion down the road. I’m highly concerned about situations where >>> taking a concrete algorithm and generalizing it (with generics) will change >>> its behavior. >> >> In this case, I think we're making == do exactly what you want it to do >> based on context. If you're working concretely with floats, then you get >> floating-point behavior like you'd expect. If you're working with >> generically Equatable/Comparable things, then you're expecting the abstract >> guarantees of interchangeability and total ordering that implies, and you >> don't want to have to think about the edge cases of weird types that violate >> those constraints. I also doubt that this will cause problems in practice. > > "then you're expecting the abstract guarantees of interchangeability and > total ordering that implies" > > Joe, please: I'm very glad that you are expert in so many subject - I'd love > to have your job - but please keep track of average joes that have to scratch > their heads whenever they have to deal with nans and infinites and subnormals > and all those weird floating beasts. They already scratch their heads with > the idiosyncrasies of Swift protocols. > > Please keep equality simple.
I would argue that keeping equality simple is exactly what this proposal achieves, since you *don't* need to worry about nans or positive/negative zero or other floating-point strangeness every place you use == abstractly. You have to opt in to the idiosyncratic behavior by working concretely with floats. -Joe _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
