> On Apr 13, 2017, at 2:42 PM, David Hart via swift-evolution
> <[email protected]> wrote:
>
> Looking good. A few comments inline:
>
>> On 13 Apr 2017, at 22:17, Ben Cohen via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>> Comparable
>>
>> Comparable will be changed to have a new ternary comparison method:
>> compare(_ other: Self) -> ComparisonResult. x.compare(y) specifies where to
>> place x relative to y. So if it yields .orderedAscending, then x comes
>> before y. This will be considered the new “main” dispatch point of
>> Comparable that implementors should provide.
>>
>> Most code will continue to use < or ==, as it will be optimal for their
>> purposes. However code that needs to make a three-way branch on comparison
>> can use the potentially more efficient compare. Note that compare is only
>> expected to be more efficient in this specific case. If a two-way branch is
>> all that’s being done, < will be more efficient in many cases (if only
>> because it’s easier for the optimizer).
>>
>> For backwards compatibility reasons, compare will have a default
>> implementation defined in terms of <, but to enable only using compare, <
>> and == will also have default implementations in terms of compare.
>>
>> The compiler will verify that either compare, or < and ==, are provided by
>> every type that claims to conform to Comparable. This will be done in some
>> unspecified way unavailable outside the standard library (it can be made
>> available to in the future, but that’s an unnecessary distraction for this
>> proposal).
>>
> It feels weird to me to jump through all these hoops just for backwards
> compatibility. Seeing how even big projects might only have several
> Comparable conformances, wouldn’t it be worth removing the default
> implementation of compare and removing < from Comparable?
The core team cares a *lot* about backwards compatibility. The engineering
effort involved in implementing this mutually-exclusive check is very small
compared with the benefits of maintaining compatibility.
- Doug
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
