[swift-evolution] [Draft][Proposal] Formalized Ordering
David Hart
david at hartbit.com
Fri Jul 22 02:29:33 CDT 2016
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.
Correct?
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?
If that is the reason, perhaps an example showing the different semantics of == and areSame for FloatingPoint would be great.
And yes, I kind of prefer areEquivalent. It does remove the identity ambiguity.
Sent from my iPhone
> On 22 Jul 2016, at 08:34, Dmitri Gribenko via swift-evolution <swift-evolution at swift.org> wrote:
>
> 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>*/
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160722/30df3be2/attachment.html>
More information about the swift-evolution
mailing list