Limit for maximumFractionDigits option for decimal strings formatting

[sffc]

This issue was originally reported as tc39/proposal-intl-numberformat-v3#34 by @Yaffle.

@Yaffle said:

I have some "numeric calculator". I am using "bigdecimal" library and so do the rounding (to specified number of digits) using the methods of that library (BigDecimal#toFixed(fractionDigits)). I am dealing with minus sign and exponents by my code (as I am trying to use MathML anyway). So NumberFormat need only convert the digits, and so maximumFractionDigits should be 2**53-1 or Infinity.

For now, I can still do the converion in JavaScript itself, as the current NumberFormat allows to get information about digits and decimal separator.

@sffc said:

The main limitation with maximumFractionDigits is that it gives us a reasonable way to limit the maximum length of the string returned from Intl.NumberFormat. If we were to raise the cap on maximumFractionDigits to something extremely large, it could be a security vulnerability, because it would become easy to make your computer run out of memory.

So in my opinion, it should be fairly harmless to increase the cap to, say, 100, 255, or perhaps a little bit larger if we have a clear use case, but increasing it to an extremely large number or Infinity voids the benefits that the cap serves in the first place.

@chicoxyzzy said:

I never needed maximumFractionDigits to be more than 20 back when I was working in a FinTech company, but I can imagine cases when limit increase could be useful.

https://brilliant.org/wiki/very-small-numbers/ - see "Important Very Small Numbers" part here

@gibson042 said during discussion:

We should be as capable as 262, but going beyond is not necessary. Looks like 100: https://tc39.es/ecma262/#sec-number.prototype.tofixed

Additional meeting discussion notes: https://github.com/tc39/ecma402/blob/master/meetings/notes-2021-07-01.md#limit-for-maximumfractiondigits-option-for-decimal-strings-formatting