[swift-evolution] Add stableSort() to the standard library.

Thorsten Seitz tseitz42 at icloud.com
Wed Jan 20 14:43:44 CST 2016

> Am 20.01.2016 um 21:19 schrieb Tyler Cloutier via swift-evolution <swift-evolution at swift.org>:
>> On Jan 20, 2016, at 9:58 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 4. I'm not a fan of adding a parameter to sort to select stability,
>>   because of the added API complexity.  People who want a
>>   faster-but-unstable sort can call unstableSort, right?
> I think the potential here is that people might not even be aware there is such an option. unstableSort() not terribly autocomplete friendly which I think adds to complexity. It seems like a parameter would be in line with API’s like print(_:separator:terminator:), even though the print arguments are not constants. I think the print API is very intuitive, but perhaps I’m misunderstanding what you mean by complexity?

I would think that for making use of unstableSort() you would have to understand what unstable sorting means in the first place and therefore it’s not unreasonable to expect that people wanting to use an unstable sort for performance reasons would actively look for one and have no problems finding it, especially if the documentation for sort() says „see also: unstableSort()“. The latter would also help other’s not (that) aware of unstable sorting to discover it.
But I’m not strongly opposed to a parameter (the default should be .Stable in that case as well, I think). It certainly helps discoverability even more than the docs.
Maybe autocomplete should point out alternatives from the „see also“ section of the documentation as well ;-)

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

More information about the swift-evolution mailing list