The largest exponents we compute are on the order of 10^21 (governed by
the maximumSignificantDigits option, which has a max value of 21). That
is too large to fit into the i64 we were using when multiplying this
exponent by the value to be formatted.
Instead, split up the logic to multiply that value by this exponent
based on the value's underlying type:
Number: Do not cast the result of pow() to an i64, and perform the
follow-up multiplication with doubles.
BigInt: Do not use pow(). Instead, compute the exponent as a BigInt
from the start, then perform the follow-up multiplication with that
BigInt.
For example, consider the locales "en-u-nu-fullwide" or "en-u-nu-arab".
The CLDR only declares the "latn" numbering system for the "en" locale,
thus ResolveLocale would change the locale to "en-u-nu-latn". This patch
allows using non-latn numbering systems digits.
In the main spec, [[UseGrouping]] can be true or false. In V3, it may be
one of:
auto: Respect the per-locale preference for grouping.
always: Ignore per-locale preference for grouping and always insert
the grouping separator (note: true is now an alias for always).
min2: Ignore per-locale preference for grouping and only insert the
grouping separator if the primary group has at least 2 digits.
false: Ignore per-locale preference for grouping and never insert
the grouping separator.
This contains minimal changes to parse newly added and modified options
from the Intl.NumberFormat V3 proposal, while maintaining main spec
behavior in Intl.NumberFormat.prototype.format. The parsed options are
reflected only in Intl.NumberFormat.prototype.resolvedOptions and the js
REPL.
Currencies are a bit strange; the layout of currency data in the CLDR is
not particularly compatible with what ECMA-402 expects. For example, the
currency format in the "en" and "ar" locales for the Latin script are:
en: "¤#,##0.00"
ar: "¤\u00A0#,##0.00"
Note how the "ar" locale has a non-breaking space after the currency
symbol (¤), but "en" does not. This does not mean that this space will
appear in the "ar"-formatted string, nor does it mean that a space won't
appear in the "en"-formatted string. This is a runtime decision based on
the currency display chosen by the user ("$" vs. "USD" vs. "US dollar")
and other rules in the Unicode TR-35 spec.
ECMA-402 shies away from the nuances here with "implementation-defined"
steps. LibUnicode will store the data parsed from the CLDR however it is
presented; making decisions about spacing, etc. will occur at runtime
based on user input.
There is quite a lot to be done here so this is just a first pass at
number formatting. Decimal and percent formatting are mostly working,
but only for standard and compact notation (engineering and scientific
notation are not implemented here). Currency formatting is parsed, but
there is more work to be done to handle e.g. using symbols instead of
currency codes ("$" instead of "USD"), and putting spaces around the
currency symbol ("USD 2.00" instead of "USD2.00").
