> On Apr 17, 2017, at 9:40 PM, Chris Lattner <[email protected]> wrote: > > >> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution >> <[email protected]> wrote: >> >> >>> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution >>> <[email protected]> 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. -Joe _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
