<div dir="ltr">On Sun, Apr 16, 2017 at 2:45 PM, Jonathan Hull <span dir="ltr"><<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</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 style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Apr 16, 2017, at 11:52 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_-3970949520697553099Apple-interchange-newline"><div><div dir="ltr">On Sun, Apr 16, 2017 at 12:58 PM, Jonathan Hull <span dir="ltr"><<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</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 style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Apr 16, 2017, at 10:45 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_-3970949520697553099m_6646175237874714548Apple-interchange-newline"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Sun, Apr 16, 2017 at 12:35 PM, Jonathan Hull via swift-evolution<span class="m_-3970949520697553099m_6646175237874714548Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evoluti<wbr>on@swift.org</a>></span><span class="m_-3970949520697553099m_6646175237874714548Apple-converted-space"> </span>wrote:<br><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-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">One benefit of the idea of using comparison metrics instead of changing comparable, is that you could just have two metrics on double. The default one which is closer to what we have now (or the new thing Xiaodi suggested with trapping NaN), and one which matches IEEE. You could in fact make a metric for each level if desired.</div></blockquote><div><br></div><div>Right, but I'm arguing that having multiple comparison metrics is _undesirable_. I see the need for one design that can accommodate unordered comparisons. I do not see the need for a second comparison metric.</div></div></div></div></div></blockquote><div><br></div></span><div>That is why there is a default metric. For most uses, what you suggest (i.e. trapping on NaN) makes sense, and that would be the default. Someone may have a need to compare in a way which differentiates NaN or matches a different IEEE level, and they can create a metric that provides that comparison, and still be able to use it with all of the algorithms in the standard library. (Note: I see those alternate metrics as living in a library as opposed to the standard library)</div></div></div></blockquote><div><br></div><div>FloatingPoint already exposes IEEE total ordering as `isTotallyOrdered`. You can use it in `sort(by:)`. That's not what I'm talking about.</div><div><br></div><div>This proposal is about the design of `Comparable`. My concern is about `<` giving different answers depending on surrounding code. I don't see the point of it. Do you?</div></div></div></div></div></blockquote><div><br></div></span><div>I agree that ‘<‘ should be consistent.</div><span class=""><div><br></div><br><blockquote type="cite"><div dir="ltr"><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"><div><div>It is clear that we will need multiple comparison metrics for some types (e.g. Case/Diacritic insensitive compare), and I am suggesting we formalize that so we don’t end up with a bunch of random ‘compare(with: optionA: optionB:)’ functions which are incompatible across types.</div></div></div></blockquote><div><br></div><div>Since the String overhaul is not done, and since localized comparison has been explicitly deferred from even the current scope of the String overhaul, I don't see how we can design around this with any sort of insight.</div></div></div></div></blockquote><div><br></div></span><div>The point is to architect away the need to know specifics ahead of time. This should work regardless of how those end up being implemented.</div><span class=""><div><br></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>In any case, again, I'm speaking specifically about the proposed design of `Comparable`. Do you think that there are meaningful generic algorithms to be written over localized string comparison and floating point comparison which are not possible today, which requires a redesign of `Comparable`?</div></div></div></div></blockquote><div><br></div></span><div><span class="m_-3970949520697553099Apple-tab-span" style="white-space:pre-wrap"> </span>sort(.ascending, using: metric) //This is defined on collection, but works with case sensitive or insensitive, diacritics, IEEE ordering, etc… It basically works for all options</div></div></div></blockquote><div><br></div><div>We already have `sort(by:)`, and if it eventually takes a `(_:_:) -> Comparison` as predicate, then it naturally should take a sort order as the first argument. The only difference from what you write above is that the label is `by` and not `using`. Not only do I not have a problem with such a function, I think this falls into the "it goes without saying" category of changes.</div><div><br></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"><div><div></div><div>It would also be fairly easy to combine with the new key paths to create composable sort descriptors.</div><div><br></div><div>Note: If you look at my design again, you will notice it isn’t really a redesign of Comparable. Instead, it mainly adds a new protocol defining a comparison metric. Compare is left alone except for gaining a defaultMetric property (which has a default implementation that calls ‘<‘ & ‘==‘). It also gains a couple of convenience methods (and convenience operator '<=>’) which can be added post-hoc. All Swift 3 code would continue working unaltered. It simply gives the option of extra efficiency and flexibility when desired.</div></div></div></blockquote><div><br></div><div>Then I don't think we're talking about the same thing. The problem is that the current Comparable protocol has conforming types which do not implement `<` suitable for stable sorting or other generic functions over Comparable, and the current Comparable does not require them to. The purpose of this pitch, and the purpose of the alternatives I'm talking about, is precisely to reform Comparable itself. By its nature it is incompatible with _all_ Swift 3 code working unaltered, and the question is how much and when alternations should be necessary.</div><div><br></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"><div><div><div class="h5"><div>Thanks,</div><div>Jon</div><br><blockquote type="cite"><div dir="ltr"><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"><div><div><div class="m_-3970949520697553099h5"><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><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-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><blockquote type="cite"><div><div class="m_-3970949520697553099m_6646175237874714548h5"><div>On Apr 13, 2017, at 8:30 PM, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-3970949520697553099m_6646175237874714548m_-3089135546296383232Apple-interchange-newline"></div></div><div><div><div class="m_-3970949520697553099m_6646175237874714548h5"><div style="word-wrap:break-word">One more thought. I am generally in favor of this proposal, but since it is in the pitch stage, I wanted to offer an alternative approach that I didn’t see mentioned. Food for thought/discussion.<div><br></div><div>What if, instead of repurposing comparable (and adding new functions for options like case insensitive compare), we define a comparison metric (with all of the options built in) and then use that to get our comparison result. Comparable things would have a default metric that uses ‘<‘ and ‘==‘ to provide a comparison result.</div><div><br></div><div>The metric would have a method which takes two things and returns a ComparisonResult. The two things would usually be the same type, but wouldn’t necessarily have to be.</div><div><br></div><div>As a convenience, any type could have a compared(to:, using:) method where you pass a comparison metric to the using parameter and receive a ComparisonResult. Comparable things could add a compared(with:) method and the spaceship operator <=>, which both use the default metric.</div><div><br></div><div>Pros:</div><div>• Would work without compiler alterations</div><div>• You can create metrics that compare items of different types</div><div>• Can setup the metric once for algorithms/comparisons with high setup cost</div><div>• Things like 'compare(to: other, using: .caseInsensitiveComparison)' fall out of the design without having to create/learn various different versions of compare on different types.</div><div>• Spaceship operator <=> for those who want it</div><div>• In some cases, it can provide a much more efficient implementation based on underlying structure. For example, you can get a metric from String/Unicode which is optimized for a particular view of that string (say ASCII). Depending on the case, when one of the objects doesn’t match the optimized type, it can either convert or fallback to a more general algorithm… but it should provide a pretty big win when most of the objects have a known structure.</div><div><br></div><div>Cons:</div><div>• More protocols defined by the design</div><div>• Requires an extra struct/class to implement in non-standard cases (e.g. case insensitive compare)</div><div>• Probably something else I am missing</div><div><br></div><div>Thanks,</div><div>Jon</div><div><div><br></div><div><br></div><div><br><div><blockquote type="cite"><div>On Apr 13, 2017, at 1:24 PM, Ben Cohen via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-3970949520697553099m_6646175237874714548m_-3089135546296383232Apple-interchange-newline"><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps: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">Online copy here:</span><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="https://github.com/airspeedswift/swift-evolution/blob/fa007138a54895e94d22e053122ca24ffa0b2eeb/proposals/NNNN-ComparisonReform.md" target="_blank">https://github.com/airspeedswi<wbr>ft/swift-evolution/blob/fa0071<wbr>38a54895e94d22e053122ca24ffa0b<wbr>2eeb/proposals/NNNN-Comparison<wbr>Reform.md</a></div></div></blockquote></div><br></div></div></div></div></div><span>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br></span></div></blockquote></div><br></div></div></div><br>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a></blockquote></div></div></div></div></blockquote></div></div></div><br></div></blockquote></div><br></div></div>
</blockquote></div></div></div><br></div></blockquote></div><br></div></div>