On Sun, Apr 16, 2017 at 12:58 PM, Jonathan Hull <[email protected]> wrote:
> > On Apr 16, 2017, at 10:45 AM, Xiaodi Wu <[email protected]> wrote: > > On Sun, Apr 16, 2017 at 12:35 PM, Jonathan Hull via swift-evolution < > [email protected]> wrote: > >> 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. >> > > 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. > > > 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) > FloatingPoint already exposes IEEE total ordering as `isTotallyOrdered`. You can use it in `sort(by:)`. That's not what I'm talking about. 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? > 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. > 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. 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`? > Thanks, > Jon > > On Apr 13, 2017, at 8:30 PM, Jonathan Hull via swift-evolution < >> [email protected]> wrote: >> >> 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. >> >> 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. >> >> 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. >> >> 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. >> >> Pros: >> • Would work without compiler alterations >> • You can create metrics that compare items of different types >> • Can setup the metric once for algorithms/comparisons with high setup >> cost >> • 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. >> • Spaceship operator <=> for those who want it >> • 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. >> >> Cons: >> • More protocols defined by the design >> • Requires an extra struct/class to implement in non-standard cases (e.g. >> case insensitive compare) >> • Probably something else I am missing >> >> Thanks, >> Jon >> >> >> >> On Apr 13, 2017, at 1:24 PM, Ben Cohen via swift-evolution < >> [email protected]> wrote: >> >> Online copy here: >> >> https://github.com/airspeedswift/swift-evolution/blob/fa0071 >> 38a54895e94d22e053122ca24ffa0b2eeb/proposals/NNNN-ComparisonReform.md >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
