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

Xiaodi Wu xiaodi.wu at gmail.com
Fri Jul 22 13:54:05 CDT 2016


On Fri, Jul 22, 2016 at 1:05 PM, Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

>
> on Thu Jul 21 2016, Duan <swift-evolution at swift.org> wrote:
>
> > Great proposal. I want to second that areSame may mislead user to
> > think this is about identity.
> >
> > I like areEquivalent() but there may be better names.
>
> It really *is* about identity as I posted in a previous message.


Correct me if I'm wrong:

Identity is an equality relation, and `==` is about just that. By contrast,
`areSame()` is to define an *equivalence* relation through which, by
default, `==` is to be dispatched. Since this design specifically
contemplates scenarios in which certain Equatables will override `==` *not*
to dispatch through `areSame()`, the latter function evaluates only
*equivalence* with respect to an arbitrary equivalence relation, not
identity.

Put another way, the future `Equatable` is a contract that conforming types
will supply a definition of equality *and* an equivalence relation, where
the former by default is dispatched through the latter; but it is
specifically envisioned that the two may be separated in domain-specific
scenarios.

But
> that doesn't change the fact that areEquivalent might be a better name.
> It's one of the things we considered; it just seemed long for no real
> benefit.
>
> > Daniel Duan
> > Sent from my iPhone
> >
> >> On Jul 21, 2016, at 6:32 PM, Robert Widmann via swift-evolution
> >> <swift-evolution at swift.org> wrote:
> >>
> >>
> >>> On Jul 21, 2016, at 6:19 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> >>>
> >>> This is nice. Is `areSame()` being proposed because static `==` is
> >>> the status quo and you're trying to make the point that `==` in the
> >>> future need not guarantee the same semantics?
> >>
> >> Yep!  Equivalence and equality are strictly very different things.
> >>
> >>>
> >>> Nit: I think the more common term in stdlib would be
> >>> `areEquivalent()`. Do you think `same` in that context (independent
> >>> of the word "ordering") might erroneously suggest identity?
> >>
> >> There is room for improvement here.  Keep ‘em coming.
> >>
> >>>
> >>>
> >>>> On Thu, Jul 21, 2016 at 8: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.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> ~Robert Widmann
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> swift-evolution mailing list
> >>>> swift-evolution at swift.org
> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>>>
> >>>
> >>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
>
> --
> Dave
>
> _______________________________________________
> 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/00e0f8ac/attachment.html>


More information about the swift-evolution mailing list