<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 22, 2016, at 8:37 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">On Fri, Jul 22, 2016 at 8:20 PM, Dave Abrahams via swift-evolution<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><span class="gmail-"><br class="">on Fri Jul 22 2016, Daniel Duan <<a href="http://daniel-at-duan.org" class="">daniel-AT-duan.org</a>> wrote:<br class=""><br class="">>> On Jul 22, 2016, at 3:00 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">>><br class="">>><br class=""></span><span class="gmail-">>> on Fri Jul 22 2016, Daniel Duan <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><span class="Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>> wrote:<br class="">>><br class="">><br class="">>>>> On Jul 22, 2016, at 11:05 AM, Dave Abrahams via swift-evolution<br class=""></span><span class="gmail-">>>>> <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><span class="Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>> wrote:<br class="">>>>><br class="">>>>><br class="">>>>> on Thu Jul 21 2016, Duan<br class="">>>><br class="">>>>> <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><span class="Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>><br class=""></span>>>>> <mailto:<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><span class="Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>>><br class=""><span class="gmail-">>>>> wrote:<br class="">>>>><br class="">>>>>> Great proposal. I want to second that areSame may mislead user to<br class="">>>>>> think this is about identity.<br class="">>>>>><br class="">>>>>> I like areEquivalent() but there may be better names.<br class="">>>>><br class="">>>>> It really *is* about identity as I posted in a previous message. But<br class="">>>>> that doesn't change the fact that areEquivalent might be a better name.<br class="">>>>> It's one of the things we considered; it just seemed long for no real<br class="">>>>> benefit.<br class="">>>>><br class="">>>><br class="">>>> If the addresses of the arguments aren’t being used, then we don’t consider<br class="">>>> them part of their *identity*. I can follow this logic. My fear is most users<br class="">>>> won’t make this leap on their own and get the same initial impression as I did.<br class="">>>> It's entirely possible this fear is unfounded. Some educated bikesheding<br class="">>>> wouldn't hurt here IMO :)<br class="">>><br class="">>> Well, it's still a very real question whether we ought to have the<br class="">>> additional API surface implied by areSame, or wether we should collapse<br class="">>> it with ===.<br class="">>><br class="">><br class="">> To spell this out (because I had to think about it for a second): === will be derived from<br class="">> <=>,<br class="">> but also becomes default implementation for ==, which remains open for<br class="">> customization.<br class=""><br class=""></span>I was imagining roughly this (untested):<br class=""><br class=""> <span class="Apple-converted-space"> </span>/// Two references are identical if they refer to the same<br class=""> <span class="Apple-converted-space"> </span>/// instance.<br class=""> <span class="Apple-converted-space"> </span>///<br class=""> <span class="Apple-converted-space"> </span>/// - Note: Classes with a more-refined notion of “identical”<br class=""> <span class="Apple-converted-space"> </span>/// should conform to `Identifiable` and implement `===`.<br class=""> <span class="Apple-converted-space"> </span>func ===(lhs: AnyObject, rhs: AnyObject) -> Bool {<br class=""> <span class="Apple-converted-space"> </span>ObjectIdentifier(lhs) == ObjectIdentifier(rhs)<br class=""> <span class="Apple-converted-space"> </span>}<br class=""><br class=""> <span class="Apple-converted-space"> </span>/// Supports testing that two values of `Self` are identical<br class=""> <span class="Apple-converted-space"> </span>///<br class=""> <span class="Apple-converted-space"> </span>/// If `a` and `b` are of type `Self`, `a === b` means that<br class=""> <span class="Apple-converted-space"> </span>/// `a` and `b` are interchangeable in most code. A conforming<br class=""> <span class="Apple-converted-space"> </span>/// type can document that specific observable characteristics<br class=""> <span class="Apple-converted-space"> </span>/// (such as the `capacity` of an `Array`) are inessential and<br class=""> <span class="Apple-converted-space"> </span>/// thus not to be considered as part of the interchangeability<br class=""> <span class="Apple-converted-space"> </span>/// guarantee.<br class=""> <span class="Apple-converted-space"> </span>///<br class=""> <span class="Apple-converted-space"> </span>/// - Requires: `===` induces an equivalence relation over<br class=""> <span class="Apple-converted-space"> </span>/// instances.<br class=""> <span class="Apple-converted-space"> </span>/// - Note: conforming types will gain an `==` operator that<br class=""> <span class="Apple-converted-space"> </span>/// forwards to `===`.<br class=""> <span class="Apple-converted-space"> </span>/// - Note: Types that require domain-specific `==`<br class=""> <span class="Apple-converted-space"> </span>/// implementations with different semantics (e.g. floating<br class=""> <span class="Apple-converted-space"> </span>/// point) should define a more-specific overload of `==`,<br class=""> <span class="Apple-converted-space"> </span>/// which will be used in contexts where the static type is<br class=""> <span class="Apple-converted-space"> </span>/// known to the compiler.<br class=""> <span class="Apple-converted-space"> </span>/// - Note: Generic code should usually use `==` to compare<br class=""> <span class="Apple-converted-space"> </span>/// conforming instances; that will always dispatch to `===`<br class=""> <span class="Apple-converted-space"> </span>/// and will be unaffected by more specific overloads of<br class=""> <span class="Apple-converted-space"> </span>/// `==`.<br class=""> <span class="Apple-converted-space"> </span>protocol Identifiable { // née Equatable name is negotiable<br class=""> <span class="Apple-converted-space"> </span>func ===(_: Self, _: aSelf) -> Bool<br class=""> <span class="Apple-converted-space"> </span>}<br class=""><br class=""> <span class="Apple-converted-space"> </span>/// Default definition of `==` for Identifiable types.<br class=""> <span class="Apple-converted-space"> </span>func ==<T: Identifiable>(lhs: T, rhs: T) -> Bool {<br class=""> <span class="Apple-converted-space"> </span>return lhs === rhs<br class=""> <span class="Apple-converted-space"> </span>}<br class=""><br class=""> <span class="Apple-converted-space"> </span>/// Conforming types have a default total ordering.<br class=""> <span class="Apple-converted-space"> </span>///<br class=""> <span class="Apple-converted-space"> </span>/// If `a` and `b` are of type `Self`, `a <=> b` means that<br class=""> <span class="Apple-converted-space"> </span>/// `a` and `b` are interchangeable in most code. A conforming<br class=""> <span class="Apple-converted-space"> </span>/// type can document that specific observable characteristics<br class=""> <span class="Apple-converted-space"> </span>/// (such as the `capacity` of an `Array`) are inessential and<br class=""> <span class="Apple-converted-space"> </span>/// thus not to be considered as part of the interchangeability<br class=""> <span class="Apple-converted-space"> </span>/// guarantee.<br class=""> <span class="Apple-converted-space"> </span>///<br class=""> <span class="Apple-converted-space"> </span>/// - Requires: `<=>` induces a total ordering over<br class=""> <span class="Apple-converted-space"> </span>/// instances.<br class=""> <span class="Apple-converted-space"> </span>/// - Requires: the semantics of `<=>` are consistent with<br class=""> <span class="Apple-converted-space"> </span>/// those of `===`. That is, `(a <=> b) == .equivalent`<br class=""> <span class="Apple-converted-space"> </span>/// iff `a === b`.<br class=""></blockquote><div class=""><br class=""></div><div class="">For floating point, I'd hope that `a === b` if `(a <=> b) == .same` *but not iff*. This is to satisfy IEEE 754: "Comparisons shall ignore the sign of zero (so +0 = −0)”.</div></div></div></div></div></blockquote><div><br class=""></div><div>The point of this design is that `===` means identity and that `.same ` also means identity.</div><div><br class=""></div><div>Since this is new territory I suppose we get to decide what identity means for floating point. Should +0 and -0 have the same identity or not? I’ll leave the answer to folks more knowledgable about numerics than I.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"> <span class="Apple-converted-space"> </span>/// - Note: conforming types will gain `<`, `<=`, `>`, and `>=`<br class=""> <span class="Apple-converted-space"> </span>/// operators defined in terms of `<=>`.<br class=""> <span class="Apple-converted-space"> </span>/// - Note: Types that require domain-specific `<`, etc.<br class=""> <span class="Apple-converted-space"> </span>/// implementations with different semantics (e.g. floating<br class=""> <span class="Apple-converted-space"> </span>/// point) should define more-specific overloads of those<br class=""> <span class="Apple-converted-space"> </span>/// operators, which will be used in contexts where the<br class=""> <span class="Apple-converted-space"> </span>/// static type is known to the compiler.<br class=""> <span class="Apple-converted-space"> </span>/// - Note: Generic code can freely use `<=>` or the traditional<br class=""> <span class="Apple-converted-space"> </span>/// comparison operators to compare conforming instances;<br class=""> <span class="Apple-converted-space"> </span>/// the result will always be supplied by `<=>`<br class=""> <span class="Apple-converted-space"> </span>/// and will be unaffected by more specific overloads of<br class=""> <span class="Apple-converted-space"> </span>/// the other operators.<br class=""> <span class="Apple-converted-space"> </span>protocol Comparable : Identifiable {<br class=""> <span class="Apple-converted-space"> </span>func <=> (lhs: Self, rhs: Self) -> Ordering<br class=""> <span class="Apple-converted-space"> </span>}<br class=""><br class=""> <span class="Apple-converted-space"> </span>/// Default implementations of `<`, `<=`, `>`, and `>=`.<br class=""> <span class="Apple-converted-space"> </span>extension Comparable {<br class=""> <span class="Apple-converted-space"> </span>static func <(lhs: Self, rhs: Self) -> Bool {<br class=""> <span class="Apple-converted-space"> </span>return (lhs <=> rhs) == .ascending<br class=""> <span class="Apple-converted-space"> </span>}<br class=""> <span class="Apple-converted-space"> </span>static func <=(lhs: Self, rhs: Self) -> Bool {<br class=""> <span class="Apple-converted-space"> </span>return (rhs <=> lhs) != .ascending<br class=""> <span class="Apple-converted-space"> </span>}<br class=""> <span class="Apple-converted-space"> </span>static func >(lhs: Self, rhs: Self) -> Bool {<br class=""> <span class="Apple-converted-space"> </span>return (lhs <=> rhs) == .descending<br class=""> <span class="Apple-converted-space"> </span>}<br class=""> <span class="Apple-converted-space"> </span>static func >=(lhs: Self, rhs: Self) -> Bool {<br class=""> <span class="Apple-converted-space"> </span>return (rhs <=> lhs) != .descending<br class=""><div class=""><div class="gmail-h5"> <span class="Apple-converted-space"> </span>}<br class=""> <span class="Apple-converted-space"> </span>}<br class=""><br class="">> I like this idea. If we keep === as a separate thing, now users have 3 “opportunities” to define<br class="">> equality. The must be few, if any, use cases for this.<br class="">><br class="">> Would love to see if anyone on the list can give us an example. Otherwise we should make<br class="">> areSame === again™!<br class="">><br class="">>>><br class="">>>>>> Daniel Duan<br class="">>>>>> Sent from my iPhone<br class="">>>>>><br class="">>>>>>> On Jul 21, 2016, at 6:32 PM, Robert Widmann via swift-evolution<br class="">>>>>>> <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">>>>>>><br class="">>>>>>><br class="">>>>>>>> On Jul 21, 2016, at 6:19 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:<br class="">>>>>>>><br class="">>>>>>>> This is nice. Is `areSame()` being proposed because static `==` is<br class="">>>>>>>> the status quo and you're trying to make the point that `==` in the<br class="">>>>>>>> future need not guarantee the same semantics?<br class="">>>>>>><br class="">>>>>>> Yep! Equivalence and equality are strictly very different things.<br class="">>>>>>><br class="">>>>>>>><br class="">>>>>>>> Nit: I think the more common term in stdlib would be<br class="">>>>>>>> `areEquivalent()`. Do you think `same` in that context (independent<br class="">>>>>>>> of the word "ordering") might erroneously suggest identity?<br class="">>>>>>><br class="">>>>>>> There is room for improvement here. Keep ‘em coming.<br class="">>>>>>><br class="">>>>>>>><br class="">>>>>>>><br class="">>>>>>>>> On Thu, Jul 21, 2016 at 8:11 PM, Robert Widmann via<br class="">>>>>>>>> swift-evolution<br class="">>>>>>>>> <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">>>>>>>>> Hello Swift Community,<br class="">>>>>>>>><br class="">>>>>>>>> Harlan Haskins, Jaden Geller, and I have been working on a<br class="">>>>>>>>> proposal to clean up the semantics of ordering relations in the<br class="">>>>>>>>> standard library. We have a draft that you can get as a gist.<br class="">>>>>>>>> Any feedback you might have about this proposal helps - though<br class="">>>>>>>>> please keeps your comments on Swift-Evolution and not on the gist.<br class="">>>>>>>>><br class="">>>>>>>>> Cheers,<br class="">>>>>>>>><br class="">>>>>>>>> ~Robert Widmann<br class="">>>>>>>>><br class="">>>>>>>>><br class="">>>>>>>>><br class="">>>>>>>>><br class="">>>>>>>>><br class="">>>>>>>>> _______________________________________________<br class="">>>>>>>>> swift-evolution mailing list<br class="">>>>>>>>><span class="Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">>>>>>>>><span class="Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">>>>>>>>><br class="">>>>>>>><br class="">>>>>>><br class="">>>>>>> _______________________________________________<br class="">>>>>>> swift-evolution mailing list<br class="">>>>>>><span class="Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">>>>>>><span class="Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">>>>>> _______________________________________________<br class="">>>>>> swift-evolution mailing list<br class="">>>>>><span class="Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">>>>>><span class="Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">>>>>><br class="">>>>><br class="">>>>> --<br class="">>>>> Dave<br class="">>>>><br class="">>>>> _______________________________________________<br class="">>>>> swift-evolution mailing list<br class="">>>>><span class="Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""></div></div>>>>> <mailto:<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><span class="Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>><br class=""><span class="gmail-">>>>><span class="Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">>>>> <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>><br class="">>>>> <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">>>>> <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>>><br class="">>>> _______________________________________________<br class="">>>> swift-evolution mailing list<br class=""></span>>>><span class="Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><span class="Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>><br class=""><span class="gmail-im gmail-HOEnZb">>>><span class="Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">>>> <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>><br class="">>>><br class="">>><br class="">>> --<br class="">>> Dave<br class="">>><br class="">>> _______________________________________________<br class="">>> swift-evolution mailing list<br class="">>><span class="Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><span class="Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>><br class="">>><span class="Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">>> <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>><br class=""><br class=""></span><div class="gmail-HOEnZb"><div class="gmail-h5">--<br class="">Dave<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></body></html>