<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="direction: inherit;">Just trying to summarize to make sure I understand. So, on most Equatable types, == and areSame will have the same semantics (return the same result for all operations), but some types will want different semantics, and that's why areSame is introduced.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">Correct?</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">If that's the case, I'm a bit perplexed on what types would want different semantics for == and areSame. Is FloatingPoint one of them? Is that why NaN is brought up in the Motivation section?</div></div><div><br><div><div style="direction: inherit;">If that is the reason, perhaps an example showing the different semantics of == and areSame for FloatingPoint would be great.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">And yes, I kind of prefer areEquivalent. It does remove the identity ambiguity.</div><br>Sent from my iPhone</div>On 22 Jul 2016, at 08:34, Dmitri Gribenko via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span>On Thu, Jul 21, 2016 at 11:09 PM, Brent Royal-Gordon via</span><br><span>swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</span><br><blockquote type="cite"><blockquote type="cite"><span>On Jul 21, 2016, at 6:11 PM, Robert Widmann via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Hello Swift Community,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Harlan Haskins, Jaden Geller, and I have been working on a proposal to clean up the semantics of ordering relations in the standard library. We have a draft that you can get as a gist. Any feedback you might have about this proposal helps - though please keeps your comments on Swift-Evolution and not on the gist.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>My thoughts on this are not yet fully formed, but I have a couple questions concerning `isSame(_:_:)` and `==`:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>* Should calls like `index(of:)` and `split(separator:)` use `==` or `isSame(_:_:)`?</span><br></blockquote><span></span><br><span>Use sites should always use `==`. They will pick up the semantics</span><br><span>appropriate for the generic constraints they see.</span><br><span></span><br><blockquote type="cite"><span>* Should `Hashable` use `==` or `isSame(_:_:)`?</span><br></blockquote><span></span><br><span>Code generic over Hashable will not see a difference.</span><br><span></span><br><blockquote type="cite"><span>* Do we know of any use cases where a type conforms to `Equatable` but not `Comparable` and needs separate `isSame(_:_:)` and `==` operators?</span><br></blockquote><span></span><br><span>No, but I can easily imagine that one exists.</span><br><span></span><br><blockquote type="cite"><span>Essentially, I'm wondering if we can leave `Equatable`'s definition alone and only change `Comparable` to require `<=>`, with a generic operator to provide a default `==` which uses `<=>`.</span><br></blockquote><span></span><br><span>We can't do that, because two values equal according to `<=>` should</span><br><span>be equal according to Equatable. Otherwise protocols don't make any</span><br><span>sense.</span><br><span></span><br><span>Dmitri</span><br><span></span><br><span>-- </span><br><span>main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if</span><br><span>(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>>*/</span><br><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>