[swift-evolution] [pitch] Comparison Reform

[Jonathan Hull]

> On Apr 13, 2017, at 2:42 PM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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?

It isn’t just backwards compatibility.  As someone who has worked with both forms of comparable, I can say that just implementing ‘<‘ is much easier, especially when you are just chaining results of comparing components.  In one case I can just use ‘||' and ‘&&’, the other may require pattern matching in a switch. (I usually still have to implement ‘==‘ anyway in both cases, so it isn’t a difference between the two).

>> Different Names For compare and ComparisonResult
>> 
>> A few different variants for ComparisonResult and its variants were considered:
>> 
>> Dropping the ordered part of ComparisonResult’s cases e.g. .ascending
>> Naming of ComparisonResult as SortOrder
>> enum Ordering { case less, equal, greater } (as used by Rust <https://doc.rust-lang.org/std/cmp/enum.Ordering.html>)
>> Case values of inOrder, same, outOfOrder
>> The choice of case names is non-trivial because the enum shows up in different contexts where different names makes more sense. Effectively, one needs to keep in mind that the “default” sort order is ascending to map between the concept of “before” and “less”.
>> 
>> The before/after naming to provide the most intuitive model for custom sorts – referring to ascending or less is confusing when trying to implement a descending ordering. Similarly the inOrder/outOfOrder naming was too indirect – it’s more natural to just say where to put the element. If the enum should focus on the sorting case, calling it SortOrder would help to emphasize this fact.
>> 
> Can you give an example where ascending/descending/equal can be confusing?

Agreed.  Ascending & Descending imply an ordering to me.  I don’t see how the extra ‘ordered’ clarifies anything…

>> This proposal elects to leave the existing Foundation name in-place. The primary motivation for this is that use of the compare function will be relatively rare. It is expected that in most cases users will continue to make use of == or <, returning boolean values (the main exception to this will be in use of the parameterized String comparisons). As such, the source compatibility consequences of introducing naming changes to an existing type seems of insufficient benefit.
>> 
>> The method compare(_:) does not fully comport with the API naming guidelines. However, it is firmly established with current usage in Objective-C APIs, will be fairly rarely seen/used (users will usually prefer <, == etc), and alternatives considered, for example compared(to:), were not a significant improvement.
>> 
> Uses of the compare function might be rare, but I still think it should follow the API naming guidelines. I don’t think that Objective-C conventions are a strong enough argument to warrant breaking those guidelines, especially in the Standard Library.

Agreed.

Thanks,
Jon

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