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. > 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/ > fa007138a54895e94d22e053122ca24ffa0b2eeb/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
