Accept decimal strings in Intl.NumberFormat

[felixfbecker]

Fixes #52124

Note: This is not a coercion like in other JS APIs that also "accept" strings by coercing them, it is specifically designed to handle arbitrary-length decimals without precision loss. This was added as an explicit feature in Intl.NumberFormat v3 (which is why I added it to es2023.intl, which also houses formatRange(), which also got added in v3): https://github.com/tc39/proposal-intl-numberformat-v3#interpret-strings-as-decimals-ecma-402-334

The format matches what ${number} accepts (plus Infinity):

The general syntax for decimal strings, essentially #.#E#, is a widely understood format in computing. The specific version we use is the ECMA-262 StringNumericLiteral grammar, which also allows non-base-10 numbers like hexadecimal and binary.

Spec link: https://tc39.es/ecma402/#sec-runtime-semantics-stringintlmv

It is very common to represent monetary numbers as strings in JSON APIs to avoid any precision loss and those can currently not be passed to the Intl.NumberFormat API without casting as any. The resulting type errors currently misleads developers into using parseFloat() to make the type error go away, which causes precision loss.

It is supported by all browsers: https://caniuse.com/mdn-javascript_builtins_intl_numberformat_format_number_parameter-string_decimal

[Renegade334]

👍 (this is the relevant feature in the spec – strings are now converted to mathematical values, rather than coerced to numbers as in previous versions)

FYI, the ECMA-402 v10 NumberFormat definitions were moved to es2023.intl since your branch, so this will need updating.

[felixfbecker]

Rebased. The new structure is nice!

[sandersn]

This makes sense to me. I'll bring the issue up at a design meeting.

[sandersn]

We agreed that this makes sense. @felixfbecker would you mind bringing the PR up to date with main?

[felixfbecker]

@sandersn Awesome, I rebased onto main! Build is passing.