[swift-evolution] [pitch] Comparison Reform

Jonathan Hull jhull at gbis.com
Thu Apr 13 22:30:41 CDT 2017


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 <swift-evolution at swift.org> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170413/8deb4506/attachment.html>


More information about the swift-evolution mailing list