Clarification on behavior of SetNumberFormatDigitOptions

[jackhorton]

Currently, https://tc39.github.io/ecma402/#sec-setnfdigitoptions sets the internal slots for fraction and integer digits in all cases, and only sets the significant digits conditionally. As a result, when calling resolvedOptions on either NumberFormat or PluralRules instances with these options set, only fraction/integer digits are reported when provided/in the default case, but significant digits are reported in addition when provided. Since significant digits override fraction/integer digits and significant digits are not included in the default case or in the case where the user provides only fraction/integer, shouldn't fraction/integer not be present when the user provides significant digits?

So, current state:

new Intl.NumberFormat("en").resolvedOptions() // -> fraction/integer returned
new Intl.NumberFormat("en", { minimumSignificantDigits: 2 }).resolvedOptions() // fraction/integer/significant returned

I feel like the following makes more sense considering the actual behavior or format/select:

new Intl.NumberFormat("en").resolvedOptions() // -> fraction/integer returned
new Intl.NumberFormat("en", { minimumSignificantDigits: 2 }).resolvedOptions() // significant returned

Also, on a much smaller note -- since SetNumberFormatDigitOptions is used by PluralRules, shouldn't it be an Intl abstract operation, rather than a NumberFormat abstract operation?

[littledan]

The logic surrounding these options is rearranged/cleaned up in https://github.com/sffc/proposal-unified-intl-numberformat . I'd suggest that, if we make further normative changes, we do it within that proposal. Actually, @sffc's currently proposed spec text may actually do what you are suggesting.

[jackhorton]

I believe it does (the internal properties for integer/fraction are set exclusively from sigfigs). We can close this if you want, or leave it open for another issue that shane's proposal fixes -- I don't mind either way.

[littledan]

Let's get confirmation from @sffc and close it if he agrees that the proposal settles the issue.

[sffc]

My new proposal adds a new internal field (which is not exposed publicly) called [[RoundingType]], which is either "significantDigits" or "fractionDigits", and the corresponding minimum/maximum values are set only when resolved to that [[RoundingType]].

Screenshot of my draft spec (copy-paste is too hard to preserve formatting):

I will list this issue as one of the ones being addressed by my proposal.

[littledan]

Awesome, closing this issue in that case.