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

[Dave Abrahams]

on Fri Jul 22 2016, Karl <swift-evolution at swift.org> wrote:

>> On 22 Jul 2016, at 03:11, 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. <https://gist.github.com/CodaFi/f0347bd37f1c407bf7ea0c429ead380e>
>> Any feedback you might have about this proposal helps - though
>> please keeps your comments on Swift-Evolution and not on the gist.
>> 
>> Cheers,
>> 
>> ~Robert Widmann
>> 
>> 
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> I fear that this will become confusing (especially since Equatable may
> now be implemented as a static function, too). We will have 3
> different “equality” comparisons in Swift:
>
> === for reference-types
> == for all types
> areSame() which may be subtly different to ==
>
> In order to have an opinion on whether or not this is justified, I
> need to know more about how areSame() may differ from == and how this
> will affect generic code. What is required that could not fit inside
> an override of Equatable? 

Floating point types.  You should be able to ask for
arrayOfFloats.firstIndex(of: x) even if there are NaNs in the array (or
x).

It will not affect generic code, since in generic code == will always
dispatch to areSame() (unless the argument is constrained to
FloatingPoint, in which case == will have floating point semantics).

It would not be wholly unreasonable to merge === and areSame; they mean
almost exactly the same thing.

> If this only applies to a few types, will it be its own protocol
> (e.g. EquivalenceCheckable)?

It applies to every type where an == operator is appropriate, as far as
I know.  That's a lot.  

Whether we should rename it something having to
do with “Equivalence” or “Identity,” etc., is a good (and separate) question.

-- 
Dave