<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 25 Jul 2016, at 21:23, Nevin Brackett-Rozinsky <<a href="mailto:nevin.brackettrozinsky@gmail.com" class="">nevin.brackettrozinsky@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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.)</span></div></blockquote></div><div class=""><br class=""></div><div class="">To sort to ascending order, you'd still just call `.sort()` with no arguments.</div><br class="">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:<div class=""><br class=""></div><div class="">1. The default .sort() function would use `<=>` instead of `<`.</div><div class=""><br class=""></div><div class="">(a) On the one hand, we'd get improved performance in cases like Array<String>.sort() where doing another `<` comparison would be more costly.</div><div class="">(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.</div><div class=""><br class=""></div><div class="">That's an additive change because (a) types implementing total order will still sort according to the same spec as `.sort(by: <)`.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">— Pyry</div><div class=""><br class=""></div></body></html>