Closed mhassan1 closed 1 year ago
This would be a breaking change, so we can't make it for ES2022 or below, but we could accommodate it in ES2023+.
I'm still not clear on the problem here; the spec doesn't actually define "code point" or "code unit" as a string or as an integer, so I made a judgement call here. What's your use case where this came up?
Given that it would be a breaking change for ES2022 and below, it probably doesn't make sense to change it for ES2023+. Closing this.
It wouldn't be the first time - what I'd do in that case is leave the ES2016-2022 PR open in case we ever did a semver-major, and land the 2023+ changes in a separate PR. What's more important tho is discussing the rationale for the change; let's do that in the issue.
As discussed in https://github.com/ljharb/es-abstract/issues/150, there's no rationale for the change. Thanks!
This PR modifies the following operations to return numbers, as specified, instead of strings:
UTF16SurrogatePairToCodePoint
UTF16DecodeSurrogatePair
UTF16Decode
UTF16DecodeString
CodePointAt
StringToCodePoints
Resolves https://github.com/ljharb/es-abstract/issues/150.