> On Apr 13, 2017, at 2:42 PM, David Hart via swift-evolution
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
