[swift-evolution] [pitch] Comparison Reform

[Xiaodi Wu]

On Sun, Apr 16, 2017 at 12:35 PM, Jonathan Hull via swift-evolution <
swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> wrote:
>
> Online copy here:
>
> https://github.com/airspeedswift/swift-evolution/blob/
> fa007138a54895e94d22e053122ca24ffa0b2eeb/proposals/NNNN-
> ComparisonReform.md
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170416/7309fe66/attachment.html>