> 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] <mailto:[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) 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. Thanks, Jon >> On Apr 13, 2017, at 8:30 PM, Jonathan Hull via swift-evolution >> <[email protected] <mailto:[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] <mailto:[email protected]>> wrote: >>> >>> Online copy here: >>> >>> https://github.com/airspeedswift/swift-evolution/blob/fa007138a54895e94d22e053122ca24ffa0b2eeb/proposals/NNNN-ComparisonReform.md >>> >>> <https://github.com/airspeedswift/swift-evolution/blob/fa007138a54895e94d22e053122ca24ffa0b2eeb/proposals/NNNN-ComparisonReform.md> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
