[swift-evolution] [Draft][Proposal] Formalized Ordering

[Dmitri Gribenko]

On Thu, Jul 21, 2016 at 11:09 PM, Brent Royal-Gordon via
swift-evolution <swift-evolution at swift.org> wrote:
>> On Jul 21, 2016, at 6:11 PM, Robert Widmann via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> Hello Swift Community,
>>
>> 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.
>
> My thoughts on this are not yet fully formed, but I have a couple questions concerning `isSame(_:_:)` and `==`:
>
> * Should calls like `index(of:)` and `split(separator:)` use `==` or `isSame(_:_:)`?

Use sites should always use `==`.  They will pick up the semantics
appropriate for the generic constraints they see.

> * Should `Hashable` use `==` or `isSame(_:_:)`?

Code generic over Hashable will not see a difference.

> * Do we know of any use cases where a type conforms to `Equatable` but not `Comparable` and needs separate `isSame(_:_:)` and `==` operators?

No, but I can easily imagine that one exists.

> 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 `<=>`.

We can't do that, because two values equal according to `<=>` should
be equal according to Equatable.  Otherwise protocols don't make any
sense.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/