[swift-evolution] [pitch] Comparison Reform

[Joe Groff]

> On Apr 18, 2017, at 1:34 AM, Gwendal Roué <gwendal.roue at gmail.com> wrote:
> 
>> 
>> Le 18 avr. 2017 à 06:45, Joe Groff via swift-evolution <swift-evolution at swift.org> a écrit :
>> 
>>> 
>>> On Apr 17, 2017, at 9:40 PM, Chris Lattner <clattner at nondot.org> wrote:
>>> 
>>> 
>>>> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> 
>>>>> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution <swift-evolution at 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