<div dir="ltr">On Fri, Jul 22, 2016 at 5:48 PM, Dave Abrahams via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
on Fri Jul 22 2016, Xiaodi Wu <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
> On Fri, Jul 22, 2016 at 3:54 PM, Dave Abrahams <<a href="mailto:dabrahams@apple.com">dabrahams@apple.com</a>> wrote:<br>
><br>
>><br>
>> on Fri Jul 22 2016, Xiaodi Wu <<a href="http://xiaodi.wu-AT-gmail.com" rel="noreferrer" target="_blank">xiaodi.wu-AT-gmail.com</a>> wrote:<br>
>><br>
>> > On Fri, Jul 22, 2016 at 1:05 PM, Dave Abrahams via swift-evolution <<br>
>> > <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>> ><br>
>> >><br>
>> >> on Thu Jul 21 2016, Duan <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>> >><br>
>> >> > Great proposal. I want to second that areSame may mislead user to<br>
>> >> > think this is about identity.<br>
>> >> ><br>
>> >> > I like areEquivalent() but there may be better names.<br>
>> >><br>
>> >> It really *is* about identity as I posted in a previous message.<br>
>> ><br>
>> > Correct me if I'm wrong:<br>
>><br>
>> Not to put too fine a point on it, but... ;-)<br>
>><br>
><br>
> Please do :) This discussion has been very edifying (for me), so thank you<br>
> for taking the time.<br>
><br>
>> > Identity is an equality relation, and `==` is about just that.<br>
>> > By contrast, `areSame()` is to define an *equivalence* relation<br>
>><br>
>> The phrase “equality relation” has no commonly-understood formal or<br>
>> informal meaning AFAIK.<br>
>><br>
>> “Identity” is a slightly informal term IIUC, but for any<br>
>> commonly-understood meaning of that word, the “is identical to” is<br>
>> *always* an equivalence relation.<br>
>><br>
>> > through which, by default, `==` is to be dispatched.<br>
>> > Since this design specifically<br>
>> > contemplates scenarios in which certain Equatables will override `==`<br>
>> *not*<br>
>> > to dispatch through `areSame()`,<br>
>><br>
>> [Since `==` wouldn't be a protocol requirement (except in FloatingPoint),<br>
>> it's technically shadowing rather than overriding in the general case.<br>
>> I imagine this detail doesn't matter to your point]<br>
>><br>
>> > the latter function evaluates only *equivalence* with respect to an<br>
>> > arbitrary equivalence relation, not identity.<br>
>><br>
>> Saying that areSame is just any old arbitrary equivalence relation,<br>
>> would complicate the system in undesirable ways.<br>
><br>
> Ah, well, there goes my dream of using `{ return true }` as my equivalence<br>
> relation... :P<br>
><br>
>> It's<br>
>> a bit subtle but I'll try to walk you through the reasoning:<br>
>><br>
>> 1. We had a choice about whether to document that Comparable requires<br>
>> that <=> be a total order or a strict weak order [A strict weak order<br>
>> is a total order over equivalence classes of elements that aren't<br>
>> ordered with respect to other members of the same class]. Either one<br>
>> will work for the standard algorithms.<br>
>><br>
>> 2. Because the concept of total order is more accessible and requiring<br>
>> <=> to be a total order doesn't seem to reduce expressivity, we<br>
>> decided on a total order.<br>
>><br>
>> 3. The only difference between these two orderings is that in a total<br>
>> order the equivalence classes have only a single element, **which<br>
>> means that the equivalence relation in play has to, in some sense,<br>
>> tell you whether two things are identical**. This all comes down to<br>
>> how you measure “are a and b the same element?”<br>
>><br>
>> The alternative is to say that <=> is just a strict weak ordering and<br>
>> areSame is just any arbitrary equivalence relation, but that really<br>
>> complicates everything (not just the definition of Comparable). For<br>
>> example, you can't document `a.firstIndex(of: b)` as the first index where<br>
>> `b` appears in `a`; you have to say it's the first index of an element<br>
>> that satisfies `{ Element.areSame($0, b) }`.<br>
>><br>
><br>
> I hadn't considered how closely yoked Equatable and Comparable have to be.<br>
> You can't have Comparable refine Equatable such that<br>
> `Comparable.areSame(_:)` has stricter semantic requirements than plain<br>
> Equatable?<br>
<br>
</div></div>Not if you want algorithms requiring Equatable to make sense. There's<br>
just no use for anything weaker than an equivalence relation.<br></blockquote><div><br></div><div>I'm assuming you mean:</div><div>s/equivalence relation/identity/ </div><div><br></div><div>In that case, I'd think collapsing `areSame(_:)` into `===` and furnishing some other way of comparing memory addresses for class types is the most sensible way to go.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
><br>
>> > Put another way, the future `Equatable` is a contract that conforming<br>
>> > types will supply a definition of equality *and* an equivalence<br>
>> > relation, where the former by default is dispatched through the<br>
>> > latter; but it is specifically envisioned that the two may be<br>
>> > separated in domain-specific scenarios.<br>
>><br>
>> That is correct. However, the equivalence relation in question still<br>
>> is, in some very real sense, an identity check.<br>
>><br>
>> >> But<br>
>> >> that doesn't change the fact that areEquivalent might be a better name.<br>
>> >> It's one of the things we considered; it just seemed long for no real<br>
>> >> benefit.<br>
>> >><br>
>> >> > Daniel Duan<br>
>> >> > Sent from my iPhone<br>
>> >> ><br>
>> >> >> On Jul 21, 2016, at 6:32 PM, Robert Widmann via swift-evolution<br>
>> >> >> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>> >> >><br>
>> >> >><br>
>> >> >>> On Jul 21, 2016, at 6:19 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br>
>> >> >>><br>
>> >> >>> This is nice. Is `areSame()` being proposed because static `==` is<br>
>> >> >>> the status quo and you're trying to make the point that `==` in the<br>
>> >> >>> future need not guarantee the same semantics?<br>
>> >> >><br>
>> >> >> Yep! Equivalence and equality are strictly very different things.<br>
>> >> >><br>
>> >> >>><br>
>> >> >>> Nit: I think the more common term in stdlib would be<br>
>> >> >>> `areEquivalent()`. Do you think `same` in that context (independent<br>
>> >> >>> of the word "ordering") might erroneously suggest identity?<br>
>> >> >><br>
>> >> >> There is room for improvement here. Keep ‘em coming.<br>
>> >> >><br>
>> >> >>><br>
>> >> >>><br>
>> >> >>>> On Thu, Jul 21, 2016 at 8:11 PM, Robert Widmann via<br>
>> >> >>>> swift-evolution<br>
>> >> >>>> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>> >> >>>> Hello Swift Community,<br>
>> >> >>>><br>
>> >> >>>> Harlan Haskins, Jaden Geller, and I have been working on a<br>
>> >> >>>> proposal to clean up the semantics of ordering relations in the<br>
>> >> >>>> standard library. We have a draft that you can get as a gist.<br>
>> >> >>>> Any feedback you might have about this proposal helps - though<br>
>> >> >>>> please keeps your comments on Swift-Evolution and not on the gist.<br>
>> >> >>>><br>
>> >> >>>> Cheers,<br>
>> >> >>>><br>
>> >> >>>> ~Robert Widmann<br>
>> >> >>>><br>
>> >> >>>><br>
>> >> >>>><br>
>> >> >>>><br>
>> >> >>>><br>
>> >> >>>> _______________________________________________<br>
>> >> >>>> swift-evolution mailing list<br>
>> >> >>>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> >> >>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>> >> >>>><br>
>> >> >>><br>
>> >> >><br>
>> >> >> _______________________________________________<br>
>> >> >> swift-evolution mailing list<br>
>> >> >> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> >> >> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>> >> > _______________________________________________<br>
>> >> > swift-evolution mailing list<br>
>> >> > <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> >> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>> >> ><br>
>> >><br>
>> >> --<br>
>> >> Dave<br>
>> >><br>
>> >> _______________________________________________<br>
>> >> swift-evolution mailing list<br>
>> >> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> >> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>> >><br>
>><br>
>> --<br>
>> Dave<br>
>><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
<br>
--<br>
Dave<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div>