Can the order in which properties are read be more comprehensible?

[gibson042]

The current state in ECMA-402 is already confusing (neither alphabetical nor logical), but I'm concerned about v3 making things even worse:

 localeMatcher
 numberingSystem
 in SetNumberFormatUnitOptions:
   style
   currency
   currencyDisplay
   currencySign
   unit
   unitDisplay
+roundingIncrement
 notation
 in SetNumberFormatDigitOptions:
   minimumIntegerDigits
   minimumFractionDigits
   maximumFractionDigits
   minimumSignificantDigits
   maximumSignificantDigits
+  roundingPriority
+trailingZeroDisplay
 compactDisplay
 useGrouping
 signDisplay
+roundingMode

Likewise for Intl.NumberFormat.prototype.resolvedOptions, which similarly doesn't clearly map to anything:

 locale
 numberingSystem
 style
 currency
 currencyDisplay
 currencySign
 unit
 unitDisplay
 minimumIntegerDigits
 minimumFractionDigits
 maximumFractionDigits
 minimumSignificantDigits
 maximumSignificantDigits
 useGrouping
 notation
 compactDisplay
 signDisplay
+roundingMode
+roundingIncrement
+trailingZeroDisplay

[sffc]

It's logical in the sense that there are dependencies going on. roundingIncrement affects _mxfdDefault_, which is needed for determining the resolved value of maximumFractionDigits, which is combined with roundingPriority to determine the final rounding strategy. Then, the new options trailingZeroDisplay and roundingMode don't have any dependencies, so they go at the end. I guess one improvement would be to actually append TrailingZeroDisplay to the end so that the order reflects the order in which these options were proposed.

[ptomato]

For Temporal we took the design principle of reading properties in alphabetical order, validating their values immediately in cases where there are no dependencies, and in case of dependencies validating them once all prerequisite values have been read.

For example, GetDifferenceSettings:

• read largestUnit and validate that it is one of the allowed units
• read roundingIncrement and validate that it is a positive integer
• read roundingMode and validate it
• read smallestUnit and validate it
• validate that largestUnit is larger than smallestUnit
• perform further validation of roundingIncrement that depends on smallestUnit

[ljharb]

(it'd be nice to s/sanity/consistency in the issue title)

[ljharb]

Regarding the issue, why not unconditionally eagerly copy the entire options object into a new null object, so that any further accesses are not observable?

[sffc]

If this were a new spec, reading out everything in alphabetical order and the resolving it later sounds like the best approach. However, since this is pre-existing spec text, the best we can do with least disruption is to slot the property reads in with all the others that are already there.

Since this particular proposal is Stage 3 and nearing Stage 4, I'm inclined to put this aside and revisit it as a normative PR to change all 402 constructors to read properties in alphabetical order.

[sffc]

TG2 discussion: https://github.com/tc39/ecma402/blob/master/meetings/notes-2023-01-12.md#can-the-order-in-which-properties-are-read-be-more-comprehensible

Conclusion: Revisit this across ECMA-402 and get alignment at that point. In the short term, there is not a change that can be made to NFv3 that is clearly better than the status quo when weighing the cost of change.

[sffc]

@gibson042 Would you mind opening an issue in the 402 repo for this?

[gibson042]

@gibson042 Would you mind opening an issue in the 402 repo for this?

Done: https://github.com/tc39/ecma402/issues/747