<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:43 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" class="">On Fri, Jul 22, 2016 at 8:42 PM, Jaden Geller <span dir="ltr" class=""><<a href="mailto:jaden.geller@gmail.com" target="_blank" class="">jaden.geller@gmail.com</a>></span> wrote:<br class=""><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 style="word-wrap:break-word" class=""><span class=""><blockquote type="cite" 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)".</blockquote><div class=""><br class=""></div></span>I don't see why both `(+0) === (-0)` and `(+0) <=> (-0)` can't return `true` and `.same`, respectively.</div></blockquote><div class=""><br class=""></div><div class="">IEEE 754 also demands that the total ordering place -0 below +0.</div></div></div></div></div></blockquote><div><br class=""></div><div>Is this the proposed total ordering for floats in Swift (sorry, I haven’t followed the details of that)? If so then it appears they must have separate identity and thus `===` would consider the sign value. You would need to use `==` if you want IEEE 754 domain specific comparison.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">This doesn't break the total ordering of values. `===` doesn't do raw memory comparison. They're "identical", so it ought to return `true`.<div class=""><div class="h5"><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jul 22, 2016, at 6:37 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">On Fri, Jul 22, 2016 at 8:20 PM, Dave Abrahams via swift-evolution<span class=""> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class=""> </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=""><br class="">on Fri Jul 22 2016, Daniel Duan <<a href="http://daniel-at-duan.org/" target="_blank" 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" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">>><br class="">>><br class=""></span><span class="">>> on Fri Jul 22 2016, Daniel Duan <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class=""> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" 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="">>>>> <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class=""> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" 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" target="_blank" class="">swift-evolution@swift.org</a><span class=""> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>><br class=""></span>>>>> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class=""> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>>>><br class=""><span class="">>>>> 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=""> </span>/// Two references are identical if they refer to the same<br class=""> <span class=""> </span>/// instance.<br class=""> <span class=""> </span>///<br class=""> <span class=""> </span>/// - Note: Classes with a more-refined notion of “identical”<br class=""> <span class=""> </span>/// should conform to `Identifiable` and implement `===`.<br class=""> <span class=""> </span>func ===(lhs: AnyObject, rhs: AnyObject) -> Bool {<br class=""> <span class=""> </span>ObjectIdentifier(lhs) == ObjectIdentifier(rhs)<br class=""> <span class=""> </span>}<br class=""><br class=""> <span class=""> </span>/// Supports testing that two values of `Self` are identical<br class=""> <span class=""> </span>///<br class=""> <span class=""> </span>/// If `a` and `b` are of type `Self`, `a === b` means that<br class=""> <span class=""> </span>/// `a` and `b` are interchangeable in most code. A conforming<br class=""> <span class=""> </span>/// type can document that specific observable characteristics<br class=""> <span class=""> </span>/// (such as the `capacity` of an `Array`) are inessential and<br class=""> <span class=""> </span>/// thus not to be considered as part of the interchangeability<br class=""> <span class=""> </span>/// guarantee.<br class=""> <span class=""> </span>///<br class=""> <span class=""> </span>/// - Requires: `===` induces an equivalence relation over<br class=""> <span class=""> </span>/// instances.<br class=""> <span class=""> </span>/// - Note: conforming types will gain an `==` operator that<br class=""> <span class=""> </span>/// forwards to `===`.<br class=""> <span class=""> </span>/// - Note: Types that require domain-specific `==`<br class=""> <span class=""> </span>/// implementations with different semantics (e.g. floating<br class=""> <span class=""> </span>/// point) should define a more-specific overload of `==`,<br class=""> <span class=""> </span>/// which will be used in contexts where the static type is<br class=""> <span class=""> </span>/// known to the compiler.<br class=""> <span class=""> </span>/// - Note: Generic code should usually use `==` to compare<br class=""> <span class=""> </span>/// conforming instances; that will always dispatch to `===`<br class=""> <span class=""> </span>/// and will be unaffected by more specific overloads of<br class=""> <span class=""> </span>/// `==`.<br class=""> <span class=""> </span>protocol Identifiable { // née Equatable name is negotiable<br class=""> <span class=""> </span>func ===(_: Self, _: aSelf) -> Bool<br class=""> <span class=""> </span>}<br class=""><br class=""> <span class=""> </span>/// Default definition of `==` for Identifiable types.<br class=""> <span class=""> </span>func ==<T: Identifiable>(lhs: T, rhs: T) -> Bool {<br class=""> <span class=""> </span>return lhs === rhs<br class=""> <span class=""> </span>}<br class=""><br class=""> <span class=""> </span>/// Conforming types have a default total ordering.<br class=""> <span class=""> </span>///<br class=""> <span class=""> </span>/// If `a` and `b` are of type `Self`, `a <=> b` means that<br class=""> <span class=""> </span>/// `a` and `b` are interchangeable in most code. A conforming<br class=""> <span class=""> </span>/// type can document that specific observable characteristics<br class=""> <span class=""> </span>/// (such as the `capacity` of an `Array`) are inessential and<br class=""> <span class=""> </span>/// thus not to be considered as part of the interchangeability<br class=""> <span class=""> </span>/// guarantee.<br class=""> <span class=""> </span>///<br class=""> <span class=""> </span>/// - Requires: `<=>` induces a total ordering over<br class=""> <span class=""> </span>/// instances.<br class=""> <span class=""> </span>/// - Requires: the semantics of `<=>` are consistent with<br class=""> <span class=""> </span>/// those of `===`. That is, `(a <=> b) == .equivalent`<br class=""> <span class=""> </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 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=""> </span>/// - Note: conforming types will gain `<`, `<=`, `>`, and `>=`<br class=""> <span class=""> </span>/// operators defined in terms of `<=>`.<br class=""> <span class=""> </span>/// - Note: Types that require domain-specific `<`, etc.<br class=""> <span class=""> </span>/// implementations with different semantics (e.g. floating<br class=""> <span class=""> </span>/// point) should define more-specific overloads of those<br class=""> <span class=""> </span>/// operators, which will be used in contexts where the<br class=""> <span class=""> </span>/// static type is known to the compiler.<br class=""> <span class=""> </span>/// - Note: Generic code can freely use `<=>` or the traditional<br class=""> <span class=""> </span>/// comparison operators to compare conforming instances;<br class=""> <span class=""> </span>/// the result will always be supplied by `<=>`<br class=""> <span class=""> </span>/// and will be unaffected by more specific overloads of<br class=""> <span class=""> </span>/// the other operators.<br class=""> <span class=""> </span>protocol Comparable : Identifiable {<br class=""> <span class=""> </span>func <=> (lhs: Self, rhs: Self) -> Ordering<br class=""> <span class=""> </span>}<br class=""><br class=""> <span class=""> </span>/// Default implementations of `<`, `<=`, `>`, and `>=`.<br class=""> <span class=""> </span>extension Comparable {<br class=""> <span class=""> </span>static func <(lhs: Self, rhs: Self) -> Bool {<br class=""> <span class=""> </span>return (lhs <=> rhs) == .ascending<br class=""> <span class=""> </span>}<br class=""> <span class=""> </span>static func <=(lhs: Self, rhs: Self) -> Bool {<br class=""> <span class=""> </span>return (rhs <=> lhs) != .ascending<br class=""> <span class=""> </span>}<br class=""> <span class=""> </span>static func >(lhs: Self, rhs: Self) -> Bool {<br class=""> <span class=""> </span>return (lhs <=> rhs) == .descending<br class=""> <span class=""> </span>}<br class=""> <span class=""> </span>static func >=(lhs: Self, rhs: Self) -> Bool {<br class=""> <span class=""> </span>return (rhs <=> lhs) != .descending<br class=""><div class=""><div class=""> <span class=""> </span>}<br class=""> <span class=""> </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" target="_blank" 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" target="_blank" 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" target="_blank" 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=""> </span><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">>>>>>>>><span class=""> </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=""> </span><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">>>>>>><span class=""> </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=""> </span><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">>>>>><span class=""> </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=""> </span><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""></div></div>>>>> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class=""> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>>><br class=""><span class="">>>>><span class=""> </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=""> </span><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class=""> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>><br class=""><span class="">>>><span class=""> </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=""> </span><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class=""> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>><br class="">>><span class=""> </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=""><div class="">--<br class="">Dave<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" 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-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">swift-evolution mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><a href="mailto:swift-evolution@swift.org" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">swift-evolution@swift.org</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>