Normative: Make DefaultNumberOption truncate before validating range

[ben-allen]

Currently the behaviour of ECMA-402 differs from ECMA-262 in that 402's DefaultNumberOption validates that the value passed in is within the specified range before truncating that value, whereas 262's toFixed truncates before range validation. This PR changes 402 to align with 262. See #691, also tc39/proposal-temporal#2296

[gibson042]

Thanks!

[michaelficarra]

From a normative perspective, this seems to go against our normative convention for rejecting non-integral arguments where we expect integers: https://github.com/tc39/how-we-work/blob/main/normative-conventions.md#integral-number-taking-inputs-should-reject-non-integral-arguments.

Why isn't this just throwing a RangeError for these invalid inputs?

[anba]

From a normative perspective, this seems to go against our normative convention for rejecting non-integral arguments where we expect integers: https://github.com/tc39/how-we-work/blob/main/normative-conventions.md#integral-number-taking-inputs-should-reject-non-integral-arguments.

Does that mean Temporal should be changed to avoid ToIntegerWithTruncation?

Why isn't this just throwing a RangeError for these invalid inputs?

We can't really change DefaultNumberOption to throw for non-integer inputs, for example new Intl.NumberFormat("en", {minimumFractionDigits: 2.5}).format(1) currently works and returns "1.00".

This PR only allows two more possible inputs:

• When zero is a valid input, x ∈ ]-1, 0[ is now additionally valid, too. Example: new Intl.NumberFormat("en", {minimumFractionDigits: -0.5}).format(1)
• When max is the maximum valid integer, x ∈ ]max, max + 1[ is now valid, too. Example: new Intl.NumberFormat("en", {minimumFractionDigits: 100.5}).format(1)

[ben-allen]

I'll put in a link to the plenary's conclusions on this PR once the notes are up on GitHub, but in the meantime here's a summary:

• We shouldn't change 402 to have the same behaviour as 262 in this case, since checking for this user error is more than valuable than consistency would be.
• It's definitely not worth the effort to change the behaviour of 262 to match 402's current behaviour.
• We'll investigate whether changing 402's behaviour to reject non-integers is worth the effort (I'm thinking no; see anba's comment above).
• Future proposals should reject non-integers in similar cases.