RFC: Why `stable=True` is the default for `xp.sort`?

[cakedev0]

In xp.sort and xp.argsort, the sort is stable by default.

I understand very well the interest for argsort: I've seen a lot of bugs because people expected np.argsort to be stable.

And I guess sort is stable by default to match argsort behavior. But:

• stable sort is slower. Typically, 8x slower in numpy on my machine.
• for totally ordered data types, stable sort output is indistinguable from unstable sort output
• for complex numbers the doc says:

For backward compatibility, conforming implementations may support complex numbers; however, inequality comparison of complex numbers is unspecified and thus implementation-dependent

So: are we sure it's a good idea to default to stable sort?

Alternatively: shouldn't we call unstable sort under-the-hood for non-complex numbers, even when stable=True?

[kgryte]

I tried to do a bit of digging regarding rationale. See #19 for the PR which added the sorting methods. I need to track down the referenced workgroup meeting minutes. Once I do, I'll try and circle back, as my memory is a little fuzzy on why stable=True apart from doing the more obvious thing and requiring users to opt-out of the obvious thing if a reproducible sort order is lower priority than perf.