search

tc39 / ecma402

Status, process, and documents for ECMA 402
https://tc39.es/ecma402/
Other
538 stars 107 forks source link

centralize currencies, collations and calendars #720

Open ryzokuken opened 3 years ago

ryzokuken commented 3 years ago

Currently, the proposal focuses on enumerating currencies, collations, calendars, numbering systems, units and time zones.

Out of these, the last three are well-specified: the list of available numbering systems and units is present in the spec, and time zones are specified as all the IANA time zones, which works pretty well.

Unlike the latter, however, the former three are not well specified. If I understand correctly, in the last TC39 meeting, @codehag expressed a concern that this may allow an implementation to return only a subset of the supported values, which I do not think is intended here. Also, as I mentioned above, this is also not internally consistent within the proposal.

I feel that this points to a larger problem in ECMA-402: because we deal with each new proposal one at a time, we may sometimes lose sight of the bigger picture. Let's take currencies as an example: including this proposal, there will be three places where currencies are used in ECMA-402, with both NumberFormat and DisplayNames. While I'm sure all implementations would like to (and infact do) support the same set of currencies in all three places, it is not mandated by the spec IIUC and I think it should be.

One way to solve this (that I managed to come up with, there might be better ones) would be to store lists of these values in internal slots of the Intl object, and normatively require all present (and future) Intl functions to support the entire list from that slot. Mind you, the contents of these lists would still be implementation-defined, but it would ensure that supporting a different set of currencies, for example, in NumberFormat than in DisplayNames would be a spec violation.

@FrankYFTang @sffc what do you folks think?

sffc commented 3 years ago

I agree that it makes sense for all Intl objects to support exactly the same set of identifiers that come out of Intl Enumeration.

We have a section toward the end of the spec that contains a centralized list of identifiers or algorithms for determining that list. Could we put this language in there somehow?

ryzokuken commented 3 years ago

I agree that it makes sense for all Intl objects to support exactly the same set of identifiers that come out of Intl Enumeration.

Good to know that we're all on the exact same page with this.

As I mentioned in the OP, the issue is not new with Enumeration, it just increases the number of redundant lists. I think we can easily do this as a normative (or editorial, since it just potentially changes the result of locale-dependent operations) PR for ECMA-402. But since that would still happen before stage 4, I suppose there will be some changes to enumeration as well.

codehag commented 2 years ago

I believe this might be appropriate to record as an invariant, which will be a way to note the rationale for aspects of the spec and why they shouldn't be changed. https://github.com/codehag/documenting-invariants/ -- I will think a bit about how that may look.

ryzokuken commented 2 years ago

Thanks @codehag, I agree that this would be a good invariant on the 402 side!

FrankYFTang commented 2 years ago

This should be a ECMA402 editorial issue, not an issue in this proposal

ryzokuken commented 2 years ago

Reopening this as it wasn't resolved completely. In my opinion, the best approach would be to unify all enumeration of any specific kind of locale data into specific abstract operations and updating all callsites to rely on the AOs.

sffc commented 2 years ago

We should resolve this once Intl Enumeration API lands.