[swift-evolution] [pitch] Comparison Reform

[Xiaodi Wu]

On Sun, Apr 16, 2017 at 12:58 PM, Jonathan Hull <jhull at gbis.com> wrote:

>
> On Apr 16, 2017, at 10:45 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> 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.
>
>
> 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)
>

FloatingPoint already exposes IEEE total ordering as `isTotallyOrdered`.
You can use it in `sort(by:)`. That's not what I'm talking about.

This proposal is about the design of `Comparable`. My concern is about `<`
giving different answers depending on surrounding code. I don't see the
point of it. Do you?


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

Since the String overhaul is not done, and since localized comparison has
been explicitly deferred from even the current scope of the String
overhaul, I don't see how we can design around this with any sort of
insight.

In any case, again, I'm speaking specifically about the proposed design of
`Comparable`. Do you think that there are meaningful generic algorithms to
be written over localized string comparison and floating point comparison
which are not possible today, which requires a redesign of `Comparable`?


> 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/fa0071
>> 38a54895e94d22e053122ca24ffa0b2eeb/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/5cdc62ca/attachment.html>