Stop incorrectly documenting the default sorting algorithms

[LilithHafner]

Notably, this is a strengthened claim. If this is change is released, then we are committed to always performing a stable sort by default (e.g. we cannot regress #42713).

(a small change with a big diff due to line width)

From #47297 (comment)

[jakobnissen]

Two questions:

• Is it breaking to stop promising the algorithm used, given that the precise algorithm was documented in the docstring?
• If a user wants to opt-in to unstable sorting for increased speed (which may not be possible now, but quite likely could be possible in the future), it's not clear how to do that. Perhaps DEFAULT_UNSTABLE should be exported and documented, with no guarantees of the underlying algorithm other than it actually correctly sorts, such that users can easily opt-in to unstable sorting?

[LilithHafner]

Is it breaking to stop promising the algorithm used, given that the precise algorithm was documented in the docstring?

Technically, yes. But the docstring was already a lie. In 1.8, we can see with @profview begin x = rand(1:3000, 10000); for _ in 1:10000 sort!(rand!(x, 1:3000)) end end (or @profile if not using VSCode) that sort!(::Vector{Int}) sometimes uses counting sort which is often faster than QuickSort in the cases when it is used, despite the fact that counting sort allocates.

I'd like to classify this loosening of the specific algorithm guarantee as a "minor change" as described by https://julialang.org/blog/2019/08/release-process/ as "technically breaking changes that are sufficiently unlikely to break anyone's code and which, in fact, do not break things in the package ecosystem as determined by running PkgEval to verify that there isn't any breakage."

We should probably run PkgEval on #45222 (or perhaps on the whole combination of 1.9 sorting changes) to support this classification.

If a user wants to opt-in to unstable sorting for increased speed (which may not be possible now, but quite likely could be possible in the future), it's not clear how to do that. Perhaps DEFAULT_UNSTABLE should be exported and documented, with no guarantees of the underlying algorithm other than it actually correctly sorts, such that users can easily opt-in to unstable sorting?

Yes. alg=Base.DEFAULT_UNSTABLE is currently the best (only) way to opt into potential future unstable optimizations. However, I'd like to consider changing that to stable=false in the future which I think is a nicer approach for when folks are willing to sacrifice stability but not interested in delving into specific algorithms and should therefore not set the alg keyword.

[KristofferC]

Is this good to go?

[LilithHafner]

Yes.