[swift-evolution] [Proposal] Formalized Ordering, take 2

[Pyry Jahkola]

> On 25 Jul 2016, at 21:23, Nevin Brackett-Rozinsky <nevin.brackettrozinsky at gmail.com> wrote:
> 
> My one question is, will I be able to write `someCollection.sort(.ascending)` and get the expected result? (This could be an additive future direction.)


To sort to ascending order, you'd still just call `.sort()` with no arguments.

To limit the scope of this proposal somewhat, I moved the introduction of new sorting functions into the Future directions section. All of those changes are additive in a way or another:

1. The default .sort() function would use `<=>` instead of `<`.

(a) On the one hand, we'd get improved performance in cases like Array<String>.sort() where doing another `<` comparison would be more costly.
(b) On the other hand, we'd get well-defined behaviour when sorting Double arrays containing NaNs, because all non-NaN values would be sorted into one contiguous subrange of the result.

That's an additive change because (a) types implementing total order will still sort according to the same spec as `.sort(by: <)`.

2. If I had it my way, the default .sort() would also become stable, and the programmer could opt in to using a faster unstable sort variant. There are cases where an unstable sort performs better, but a stable sort is a better default, not least because it's usually what people want when sorting a table by a given column.

3. Several functions (e.g. `.sort(by:)`) would be paired with a `frobnicate(ordering:)` variant where the block returns `Ordering` instead of `Bool`. For sorting to descending order, you'd call something like `someCollection.sort(ordering: Ordering.reversing(<=>))`. Or whatever naming we'll end up with.

— Pyry

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