Intl.NumberFormat.prototype.format parameter type is too strict

[asakusuma]

lib Update Request

I'm happy to open up a PR here, but wanted to open an issue first to discuss.

Configuration Check

My compilation target is ES2017 and my lib is the default.

Missing / Incorrect Definition

The types for Intl.NumberFormat.prototype.format require a number type, even though the TC39 spec does not require the input parameter to be a number and will handle string input.

Sample Code

// This will throw a type error because the input is a string, even though the browser will actually handle a string
new Intl.NumberFormat('en-US').format('100');

https://www.typescriptlang.org/play?#code/HYUw7gBAksAuA2A6AcgVwLYCMQCcBiA9jugIawAUA5CMALQCqAypQDQCUiAZkaRZQIwAGQZTYBuIA

Documentation Link

1. https://tc39.es/ecma402/#sec-intl.numberformat.prototype.format
2. https://tc39.es/ecma402/#sec-number-format-functions
3. https://tc39.es/ecma262/#sec-tonumeric
4. https://tc39.es/ecma262/#sec-tonumber

[fatcerberus]

There is no undefined behavior in JS, only unintuitive behavior. To this end, many functions in JS perform automatic coercion like this but TS still considers it a type error to exploit it because it won't always do what you expect. See, e.g., #4002 and https://stackoverflow.com/questions/41750390/what-does-all-legal-javascript-is-legal-typescript-mean

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[yseymour]

@RyanCavanaugh, would you reconsider this one? IMO, this is qualitatively different from regular number conversions in that the spec mandates that it be done without loss of precision, and there's no "correct" alternative way of accessing that behaviour.

Current engines seem to deal with this:

> fmt = Intl.NumberFormat("en-AU", { minimumFractionDigits: 20, style: "currency", currency: "AUD" })
NumberFormat [Intl.NumberFormat] {}
> fmt.format("100000000000000000.00000000000000000001")
'$100,000,000,000,000,000.00000000000000000001'

[mkarajohn]

I get this but in this case passing a string also results in distinct behaviour compared to regular number conversions, as documented, per @yseymour 's reference.

Maybe the case for Intl.NumberFormat.prototype.format should be reconsidered? @RyanCavanaugh

[felixfbecker]

As others have stated, it's not a coercion in this API, it is specifically to support arbitrary-precision decimals (e.g. monetary numbers). 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 misleads developers into using parseFloat() to make the type error go away, which causes precision loss.

This was explicitly added as a feature in Intl NumberFormat v3: https://github.com/tc39/proposal-intl-numberformat-v3#interpret-strings-as-decimals-ecma-402-334