Awkward rounding behavior when currencies are used

[sffc]

The spec reads:

Section 11.1.2:

Let cDigits be CurrencyDigits(currency).
...
Let mnfdDefault be cDigits.
Let mxfdDefault be cDigits.
...
Perform ? SetNumberFormatDigitOptions(numberFormat, options, mnfdDefault, mxfdDefault).

Section 11.1.1:

Let mnfd be ? GetNumberOption(options, "minimumFractionDigits", 0, 20, mnfdDefault).
Let mxfdActualDefault be max( mnfd, mxfdDefault ).
Let mxfd be ? GetNumberOption(options, "maximumFractionDigits", mnfd, 20, mxfdActualDefault).

Fine. So say I use a currency that sets mnfdDefault=2 and mxfdDefault=2. However, I want to override the rounding so that I get integer rounding (no fraction digits). I try to set options.maximumFractionDigits to 0.

new Intl.NumberFormat("en", { style: "currency", currency: "EUR", maximumFractionDigits: 0 });

RangeError!

VM61:1 Uncaught RangeError: maximumFractionDigits value is out of range.
at new NumberFormat (native)
at :1:1

Although consistent with the spec, this is bad behavior for a number of reasons:

1. Currency default fraction digits could change over time (unlikely but possible), meaning different versions of CLDR could trigger the exception but not others.
2. It is just bad behavior from a user's perspective.

I would like to fix up the spec so that RangeError is thrown only when the user's minimumFractionDigits and maximumFractionDigits are in conflict with each other, not when they are in conflict with some random CLDR currency rounding data.

[rxaviers]

I would like to fix up the spec so that RangeError is thrown only when the user's minimumFractionDigits and maximumFractionDigits are in conflict with each other, not when they are in conflict with some random CLDR currency rounding data.

Sounds good. Your suggestion makes API more consistent (e.g., consistent with new Intl.NumberFormat("en", { maximumFractionDigits: 0 })) and it doesn't break existing usage (e.g., setting both mnfd and mxfd is still fine new Intl.NumberFormat("en", { style: "currency", currency: "EUR", minimumFractionDigits: 0, maximumFractionDigits: 0 }).

PS: Interestingly, on some environments (e.g., Node 4) it works as you would expect (instead of the spec).

new Intl.NumberFormat("en", { style: "currency", currency: "EUR", maximumFractionDigits: 0 }).format(1);
// > '€1'

[littledan]

Sounds good. I bet the current logic has these particular edge cases because it seemed like a reasonable way to specify; at least in V8, it seems like it'd be reasonable to loosen the restrictions.

For a small change like this, I'd suggest that the next steps would be:

1. A PR to this specification which describes the new logic. We can review that here on GitHub
2. Test262 tests for the change
3. A draft implementation, e.g., in V8 (I'd recommend not shipping it though)
4. Review the change in the Intl call
5. Present the change at TC39
6. Merge the PR into the specification

[littledan]

What's the plan for this issue? Do you plan to pursue it, @sffc ? Should we discuss it at the Intl meeting this week. I was suggesting above that this could be an independent needs-consensus PR, but you could also do it as part of your broader NumberFormat changes.

[sffc]

I want to discuss this along with tc39/proposal-unified-intl-numberformat#9.

[sffc]

The spec still requires a RangeError on the code in the OP.

// mnfd and mxfd are the user-provided options.
// For USD: mnfdDefault == mxfdDefault == 2.

Let mnfd be ? DefaultNumberOption(mnfd, 0, 20, mnfdDefault).
Let mxfdActualDefault be max( mnfd, mxfdDefault ).
Let mxfd be ? DefaultNumberOption(mxfd, mnfd, 20, mxfdActualDefault).

In the above case, for USD, when mnfd == undefined and mxfd == 0, we get a RangeError on the second call to DefaultNumberOption.

The next step on this issue is to open a PR changing the above logic to not throw a RangeError in this case. But first, let's confirm with the committee that we want to introduce this behavior change.