[swift-evolution] [pitch] Comparison Reform

[Goffredo Marocchi]

Sent from my iPhone

> On 23 Apr 2017, at 05:58, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Apr 22, 2017, at 6:06 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>> but my quick reaction to `&==` is that it would make me quite nervous to have `==` not bound to 754-equals as it is in essentially every other language. In particular, I worry about the risk of people porting numerical code that depends on isnan(x) <—> !(x < y) in non-obvious ways that they are unlikely to test. I’ll try to follow up with more detailed thoughts tomorrow.
>> 
>> Indeed, it makes me a little nervous too. That said, `==` being either bound or not bound to 754 depending on the context is what makes me even more nervous.
>> 
>> I was once adamantly against a new spelling for `==`, but on reconsideration it's clear to me that few if any numerical recipes can be ported verbatim from C-like languages and we should probably not encourage people to do so. Already, `+` needs to be rewritten as `&+`, `<<` probably should be rewritten as `&<<` (I still haven't had enough time to think about this), and the bitwise operators have differing precedences that require careful proofreading.
> 
> 
> I haven’t been following this proposal or discussion closely, but it seems to me that there are a few workable approaches with different tradeoffs:
> 
> 1. The strictly correct but user hostile approach:
> 
> * == and != are tied to the Equatable protocol, which is essentially the == operation.
> * <, <=, >, >= are tied to the Comparable protocol, which is essentially the <=> operation.
> * Hashable doesn’t require equatable, it requires a related StrictlyEquatable protocol.
> * StrictlyEquatable refines Equatable (with no other requirements, it is just a marker protocol), in which case FP types can’t conform to it, and thus can’t participate as dictionary keys
> 
> => This approach sucks because you can’t have Set<Float>, or Dictionary<Float, String>.
> 
> 2. The strictly correct but somewhat user hostile approach:
> 
> * == and != are tied to the Equatable protocol, which is essentially the == operation.
> * <, <=, >, >= are tied to the Comparable protocol, which is essentially the <=> operation.
> * Hashable doesn’t require equatable, it requires a related StrictlyEquatable protocol.
> * StrictlyEquatable doesn’t refine Equatable: it has a different requirement, and FP types can therefore implement both Equatable and StrictlyEquatable.
> 
> => This approach is suboptimal because implementing your own type requires you to implement the <=> operation, as well as the StrictlyEquatable protocol, both.
> 
> 3. The user friendly but incorrect model:
> 
> * == and != are tied to the Equatable protocol, which is essentially the == operation.
> * <, <=, >, >= are tied to the Comparable protocol, which is essentially the <=> operation.
> * Hashable is defined in terms of Equatable.
> 
> => This is easy (types just have to define <=>), but fails for FP types.
> 
> 
> I don’t think that this proposal is acceptable as written.  I think it is really bad that abstracting a concrete algorithm would change its behavior so substantially.  

Agreed, it seems a bit more like changing behaviour and adding side effects in order to allow a generic abstraction instead of the generic abstraction servicing the user and language needs and improving the status quo.

> I don’t care about SNaNs, but I do care about the difference between +0/-1 and secondarily that of NaN handling.  It seems really bad that generalizing something like:
> 
> func doThing(a : Double, b : Double) -> Bool {
>   ….
>   return a != b
> }
> 
> to:
> 
> func doThing<T : FloatingPoint> (a : T, b : T) -> Bool {
>   ….
>   return a != b
> }
> 
> would change behavior (e.g. when a is -0.0 and b is +0.0).   Likewise, "T : Equatable".
> 
> -Chris
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution