Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit for maximumFractionDigits option for decimal strings formatting #34

Closed
Yaffle opened this issue May 20, 2021 · 5 comments
Closed
Labels
discuss Needs discussion to make progress

Comments

@Yaffle
Copy link

Yaffle commented May 20, 2021

Current limit is 20.

@sffc
Copy link
Collaborator

sffc commented May 20, 2021

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
Copy link
Author

Yaffle commented May 20, 2021

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
Copy link
Collaborator

sffc commented May 20, 2021

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
Copy link
Member

chicoxyzzy commented Jul 1, 2021

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
Copy link
Collaborator

sffc commented Jul 2, 2021

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

@sffc sffc closed this as completed Jul 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Needs discussion to make progress
Projects
None yet
Development

No branches or pull requests

3 participants