Editorial: Improve case sensitivity and conversion #625
Conversation
| 1. Else, | ||
| 1. Assert: _targetCase_ is ~upper~. | ||
| 1. Let _newCodePoints_ be a List whose elements are the result of an upper case transformation of _codePoints_ according to an implementation-derived algorithm using _locale_ or the Unicode Default Case Conversion algorithm. | ||
| 1. Return ! CodePointsToString(_newCodePoints_). |
There was a problem hiding this comment.
This algorithm is technically omitting a possible error, but I'm not fully decided about how to remedy that. It occurs because ECMAScript String values are bounded to a maximum of 253 - 1 code units and some case transformations can increase length, meaning there are inputs for which the output is well-defined but not representable (e.g., "ß".repeat(2**53 - 1).toLocaleUpperCase("en")). I think the right approach is updating CodePointsToString (which is defined in ECMA-262) to throw an error when its input corresponds to out-of-bounds output and then updating this invocation to be explicitly fallible with ?, although I'm willing to wait on that because AFAICT every current implementation is incapable of dealing with strings near the limit.
There was a problem hiding this comment.
gibson042
force-pushed
the
2021-11-ascii-consistency
branch
from
6c13224 to
314e4c2
Compare
No description provided.