Sent from my iPhone
> On 23 Apr 2017, at 05:58, Chris Lattner via swift-evolution > <[email protected]> wrote: > >> On Apr 22, 2017, at 6:06 PM, Xiaodi Wu <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
