Closed Josh-Cena closed 8 months ago
[[Locale]]
and [[NumberingSystem]]
should be switched, so that the order is
Does Anba's ordering result in a normative change from the spec pre-#150?
Normative-wise, yes, because [[NumberingSystem]] is now second instead of last.
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
@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?
[[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:
[[Calendar]]
and [[NumberingSystem]]
right after [[Locale]]
. [[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 https://github.com/tc39/proposal-intl-relative-time/pull/100. We may want to consider reordering the output of Intl.RelativeTimeFormat.prototype.resolvedOptions
.
This is a rehash of https://github.com/tc39/proposal-intl-duration-format/issues/30.
The ordering was fixed in https://github.com/tc39/proposal-intl-duration-format/commit/02584a571517ae261fefeae7234f0c83d7b428a4, but then reordered again in https://github.com/tc39/proposal-intl-duration-format/pull/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 andlocale
first.