It is fairly common for applications to handle numeric data that cannot be represented as a JavaScript number.
-
One enormous application uses 64-bit integers (represented by a triple of Smi values) with an implicit 6 decimal digit scaling, aka 'MicroMoney'. It is necessary to format these values without intermediate rounding or truncation from conversion to Number.
-
It should be possible to format the recently added JavaScript BigInt type with a NumberFormat. Note that BigInt by design provides no conversion to Number to prevent accidental truncation. ToNumber conversions throw.
-
There are numerous libraries for monetary or 'decimal' values that could benefit from consistent formatting.
-
There are extended precision libraries that could benefit from consistent formatting.
In the case of BigInt and extended precision libraries, the bounds on the allowable formatting parameters don't make much sense. A BigInt could have 100 digits, but should still be formatted with the localized digit grouping. An extended floating-point library should not be limited to 21 significant digits.
I'd like to see NumberFormat be capable of formatting these inputs. It is reasonable to expect these inputs to provide an API for digit generation, but Intl should handle everything that is localized.
As it currently stands applications contain an approximation to Intl.NumberFormat written in (or compiled to) JavaScript. The quality of the approximation varies, but the good ones are quite expensive, with measurable application startup latency due to effectively cloning part of ICU in the JavaScript code.
It is fairly common for applications to handle numeric data that cannot be represented as a JavaScript number.
One enormous application uses 64-bit integers (represented by a triple of Smi values) with an implicit 6 decimal digit scaling, aka 'MicroMoney'. It is necessary to format these values without intermediate rounding or truncation from conversion to Number.
It should be possible to format the recently added JavaScript BigInt type with a NumberFormat. Note that BigInt by design provides no conversion to Number to prevent accidental truncation. ToNumber conversions throw.
There are numerous libraries for monetary or 'decimal' values that could benefit from consistent formatting.
There are extended precision libraries that could benefit from consistent formatting.
In the case of BigInt and extended precision libraries, the bounds on the allowable formatting parameters don't make much sense. A BigInt could have 100 digits, but should still be formatted with the localized digit grouping. An extended floating-point library should not be limited to 21 significant digits.
I'd like to see NumberFormat be capable of formatting these inputs. It is reasonable to expect these inputs to provide an API for digit generation, but Intl should handle everything that is localized.
As it currently stands applications contain an approximation to Intl.NumberFormat written in (or compiled to) JavaScript. The quality of the approximation varies, but the good ones are quite expensive, with measurable application startup latency due to effectively cloning part of ICU in the JavaScript code.