Numeric range validation is inconsistent

[gibson042]

trafficstars

DefaultNumberOption (used by GetNumberOption and SetNumberFormatDigitOptions for processing options like "fractionalSecondDigits", "minimumIntegerDigits", and "{minimum,maximum}{Fraction,Significant}Digits") converts its primary argument to a Number value, validates the result against the range bounds, and then returns its truncation (implemented with floor but equivalent because no existing use specifies a negative lower bound).

As a result, implementations are required to exhibit strange behavior like minimumFractionDigits 19.9 being synonymous with 19 but 20.9 not being synonymous with 20. It is also inconsistent with ECMA-262, in which e.g. x.toFixed(-0.9) is synonymous with x.toFixed(0) and x.toFixed(100.9)is synonymous with x.toFixed(100).

This is coming up in https://github.com/tc39/proposal-temporal/issues/2296 , which affects new ECMA-262 behavior inspired by ECMA-402. I think the divergence between ECMA-262 and ECMA-402 here should be reduced, allowing Temporal to comfortably adopt the latter without being too jarring in the context of the former. Specifically, ECMA-402 DefaultNumberOption should perform range validation after truncation (converting some current RangeError cases into valid input) but maintain rejection of non-numeric input:

         1. If _value_ is *undefined*, return _fallback_.
         1. Set _value_ to ? ToNumber(_value_).
-        1. If _value_ is *NaN* or less than _minimum_ or greater than _maximum_, throw a *RangeError* exception.
-        1. Return floor(_value_).
+        1. If _value_ is *NaN*, throw a *RangeError* exception.
+        1. Let _value_ be truncate(ℝ(_value_)).
+        1. If _value_ < _minimum_ or _value_ > _maximum_, throw a *RangeError* exception.
+        1. Return _value_.

(note: truncate will be added to ECMA-262 by https://github.com/tc39/ecma262/pull/2781 ; for nonnegative input it is equivalent to floor)

[sffc]

2024-03-28 TG2 notes: https://github.com/tc39/ecma402/blob/main/meetings/notes-2024-03-28.md#numeric-range-validation-is-inconsistent-691

[ben-allen]

I'll post notes from the plenary's discussion of https://github.com/tc39/ecma402/pull/908 when they're up, but in the meantime the short of it is that:

• 262 can't change, since the effort required to change it would be much greater than the benefit changing it would produce.
• The value of having the additional error check in 402 is greater than the value of consistency between 262 and 402.

[ben-allen]

Closing due to plenary decision that the inconsistency between 262 and 402 is less important than having additional error check in 402.