resolvedOptions order

[Josh-Cena]

This is a rehash of #30.

The ordering was fixed in 02584a5, but then reordered again in #150.

I wonder if the decision was intentional, since it makes locale come out second. This is observable at runtime.

JSC currently still puts numberingSystem last and locale first.

[anba]

[[Locale]] and [[NumberingSystem]] should be switched, so that the order is

1. [[Locale]]
2. [[NumberingSystem]]
3. [[Style]]
4. [[YearsStyle]], [[YearsDisplay]], etc.
5. And [[FractionalDigits]] as the last entry.

[ben-allen]

Does Anba's ordering result in a normative change from the spec pre-#150?

[Josh-Cena]

Normative-wise, yes, because [[NumberingSystem]] is now second instead of last.

[FrankYFTang]

The spec which passed Stage 3 is in the following order

locale
style
years
yearsDisplay
months
monthsDisplay
weeks
weeksDisplay
days
daysDisplay
hours
hoursDisplay
minutes
minutesDisplay
seconds
secondsDisplay
milliseconds
millisecondsDisplay
microseconds
microsecondsDisplay
nanoseconds
nanosecondsDisplay
fractionalDigits
numberingSystem

the order got changed accidentially while merging PR 150 then I just merged PR 165 to correct that accidental change.

So I reopen this issue if we want to chagne the order. That need to be discuss and reach consensus in TC39 with a Normative PR

[FrankYFTang]

@anba, could you explain why you say

[[Locale]]
[[NumberingSystem]]
[[Style]]
[[YearsStyle]], [[YearsDisplay]], etc.
And [[FractionalDigits]] as the last entry.

I am not agree (nor disagree) with you. Just want to make sure we all understand the reasoning of that.

Is that because that align with the access order of the information from the option bag?

[anba]

[[NumberingSystem]] should appear right after [[Locale]] to match other Intl constructors, which generally have properties from Unicode extension keys right after [[Locale]] [1, 2]:

For example:

• Intl.DateTimeFormat has [[Calendar]] and [[NumberingSystem]] right after [[Locale]].
• Intl.NumberFormat has [[NumberingSystem]] right after [[Locale]].

Is that because that align with the access order of the information from the option bag?

Yes, I think so. Intl.NumberFormat doesn't match this anymore, but I think the other constructors still align the resolvedOptions object with the access order in the constructor function. (Maybe except hour12, which got reordered later when support for hourCycle was added.)

---

[1] Intl.Collator is an exception, because its Unicode extension properties numeric and caseFirst are optional, because support for kn and kf is optional.

[2] Intl.RelativeTimeFormat does not have [[NumberingSystem]] right after [[Locale]]. We probably overlooked this when adding it in tc39/proposal-intl-relative-time#100. We may want to consider reordering the output of Intl.RelativeTimeFormat.prototype.resolvedOptions.