[swift-evolution] [pitch] Comparison Reform

[Douglas Gregor]

> On Apr 13, 2017, at 2:42 PM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Looking good. A few comments inline:
> 
>> On 13 Apr 2017, at 22:17, Ben Cohen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170413/740eb666/attachment.html>