Use case seems valid but is relatively narrow

[sffc]

I can be convinced that this proposal is motivated by the fact that UTF-8 proliferates widely on the Web and in other software, and it is valuable for JS to interoperate with those systems.

The main risk from my point of view is that I don't want developers to see this new shiny function and think they should generally be using it for sorting. This is a solvable problem by making sure that the function is named appropriately and with appropriate documentation.

Therefore, it would be really useful to see more specific use cases and call sites that would benefit from having this function. For example, why is a built-in function better than the SQLite library just exporting a SQLite.stringCompare function?

[bakkot]

Re: naming, I think compareByCodePoint would suffice - hardly anyone even knows what code points are, and among those who do most people (correctly) understand that code points are a computer-facing thing rather than a human-facing thing and so are not appropriate for sorting data for presentation to humans.

[gibson042]

@sffc Given that the overwhelming supermajority of standard library functions can be implemented manually in ECMAScript code (including proposal-arraybuffer-base64, which this is spiritually similar to), what are your criteria? A codePointCompare function is appropriate any time a collection of strings is shared with an external system or cross-language implementation that requires determinism, and as such arises in domains like JMESPath, data formats, canonicalization, and font construction.

[sffc]

Well, that's a fairly profound question.

We have listed out specific requirements in ECMA-402. They largely fall into "make it easier to do the right thing" (which includes ergonomics) or "make code more efficient" (which includes reducing code/data size).

Browsers typically consider "helps the user" as the litmus test (where the "user" is the user of the Web, not necessarily the developer). Making it easier for the developer to do the right thing in a way that prevents bugs can qualify for this.

So, I was asking for examples in order to add color to the argument that having this function helps programmers do the right thing.

[Manishearth]

One of my former web standards colleagues used to encourage framing things in terms of "pits of success" and "pits of failure": are we building a pit of success or a pit of failure? If it is likely that people will misuse it, that's a problem. It may be mitigated, but it's a problem to be dealt with.

This API feels like one that has some highly specific use cases, but may also be misused by people who misunderstand their needs. That's probably something that should be addressed.

[gibson042]

Where strings.sort(codePointCompare) is a pit of failure, so too is the more ergonomic zero-argument strings.sort() (which differs only in the lexicographic treatment of U+E000 through U+FFFF relative to supplementary code points at or above U+10000), and there's no incentive to reach for this new function unless it actually is appropriate.

Given that, I think this issue has been addressed. To summarize:

I was asking for examples in order to add color to the argument that having this function helps programmers do the right thing.

why is a built-in function better than the SQLite library just exporting a SQLite.stringCompare function?

The use cases identified in #4 (comment) are not limited to SQLite.

They largely fall into "make it easier to do the right thing" (which includes ergonomics) or "make code more efficient" (which includes reducing code/data size).

I believe this proposal satisfies both—a manual implementation (especially one that values performance and/or robust correctness) is rather dense.