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 > > <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
