Limit for maximumFractionDigits option for decimal strings formatting about proposal-intl-numberformat-v3

[sffc]

Do you have a suggestion about how high the limit should be raised? What are the use cases you're looking at?

Due to implementation concerns, I think we should not go above 255 without a solid use case, and if we have a limit, perhaps something lower like 100 would be reasonable.

[Yaffle]

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]

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]

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

[sffc]

We decided in the 2021-07-01 meeting to decouple this issue from the NFv3 proposal. tc39/ecma402#585