UTF-16 sort order is not wrong

[sffc]

I see two main use cases for sorting in an isolated JS environment (interop aside, #4):

1. A total ordering for use in a BTree-like data structure
2. A human-readable ordering

(1) is served by UTF-16 ordering. (2) is better-served by Intl.Collator.

There is no reason to use code point ordering for a JS-internal data structure. In fact, it is harmful since no sort order is likely to be faster than UTF-16 order.

The README seems to have an underlying assumption that UTF-16 order is "wrong" in some way. For example, it suggests that if we weren't beholden to the web reality, JS might consider using this behavior for the < operator.

[macchiati]

The only use case I can see is that you could get the same sort order in a web app as you do in a backend server. For example, you might have a sorted table that is populated on a server for first display, but then allows further modification (eg insertions).

However, I think that's an edge case because you so very rarely want a sorted table presented to a user in codepoint order; it is wrong for essentially every human language.

[bakkot]

I think there's a lot of not-for-human-consumption cases that don't care exactly what the order is but do care that it's consistent between client and server, and if the server is written in a language other than JS the easiest way to do that is going to be code point order.

[sffc]

I think there's a lot of not-for-human-consumption cases that don't care exactly what the order is but do care that it's consistent between client and server, and if the server is written in a language other than JS the easiest way to do that is going to be code point order.

I believe that these cases exist, and the README does mention "Interoperability with other systems", but I'd like to see at least some evidence about use cases that are better served by a built-in function than a userland function (#4).