tc39
Normative: Increase limits on Intl MV and explicitly limit significant digits
See #1017
The intent of this PR is the following. In this table, 99~9 stands in for 9999 digit 9s, and 999~9 stands in for 10000 digit 9s.
| Input String MV | Resolved MV | Comments |
|---|---|---|
| 1e9999 | 1e9999 | |
| 99~9e9999 | 99~9e9999 | |
| 99~9.999~9e9999 | 99~9.999~9e9999 | Largest in-bounds value |
| 1e10000 | ∞ | Smallest out-of-bounds value |
| 1e-10000 | 1e-10000 | Smallest in-bounds value |
| 9e-10001 | 0 | |
| 0.999~9 | 0.999~9 | |
| 0.999~98 | 0.999~9 | Truncate such that the least significant digit is at 1e-10000 |
| 1.9e-10000 | 1e-10000 | ^ |
| 1.234e-9998 | 1.23e-9998 | ^ |
Just a note on the significant digits truncation: this could technically change the behavior of numbers so close to the edge of a rounding boundary where the discriminator is at a position less than -10000; for example, 2.5 followed by 10000 zeros followed by 1, with half-even rounding. In the current spec, that number should round up to 3, but in this new spec, that number should round down to 2 since the significant digit is dropped during parsing, not during rounding. I think people like to call this "double rounding".
If this is a problem (it might not be: 10000 digits is beyond all known use cases), it can be fixed by performing a bigger refactoring of the spec in order to avoid the spec-required double rounding, but actually it is easier to implement if the truncation happens during parsing.
Could someone confirm that this approach would not cause any issues with implementations that rely on ICU4C or ICU4J?
ICU4C (and ICU4J) have a similar representation as ICU4X but use int32_t for the fields.
https://github.com/unicode-org/icu/blob/3a66f8c5fecfc3f0ee427c12b90966bac1b02d92/icu4c/source/i18n/number_decimalquantity.h#L361
TG2 discussion: https://github.com/tc39/ecma402/blob/main/meetings/notes-2025-08-14.md#normative-increase-limits-on-intl-mv-and-explicitly-limit-significant-digits-1022
@erights It was suggested that we bring this PR to TG3. Could it be added to an upcoming TG3 agenda?
Kris?
On Thu, Aug 14, 2025 at 8:55 PM Shane F. Carr @.***> wrote:
sffc left a comment (tc39/ecma402#1022) https://github.com/tc39/ecma402/pull/1022#issuecomment-3190533039
@erights https://github.com/erights It was suggested that we bring this PR to TG3. Could it be added to an upcoming TG3 agenda?
— Reply to this email directly, view it on GitHub https://github.com/tc39/ecma402/pull/1022#issuecomment-3190533039, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACC3THL6LFDUYKUITH7ZGL3NVK4DAVCNFSM6AAAAACDPLFRVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCOJQGUZTGMBTHE . You are receiving this because you were mentioned.Message ID: @.***>
-- Cheers, --MarkM
TG2 conditional approval; we will defer to TG1 on exactly what bounds to use: https://github.com/tc39/ecma402/blob/main/meetings/notes-2025-09-11.md#normative-increase-limits-on-intl-mv-and-explicitly-limit-significant-digits-1022
The description above doesn't match what the algorithm is doing. I assume this is due to typos in the description? I don't see why 10e9999 would be in-bounds while 1e10000 would be out of bounds (it's the same mathematical value), which is what the description above is currently stating.
The algorithm changes look good, once the bug when intlMV is zero is fixed.
