stage 3 review

[ljharb]

unrelated to the review: i noticed https://tc39.es/ecma402/#sec-canonicalizelocalelist and https://tc39.es/ecma402/#sec-getoption don't auto-link from the proposal spec, altho https://tc39.es/ecma402/#table-numbering-system-digits and https://tc39.es/proposal-intl-enumeration/#table-sanctioned-simple-unit-identifiers do (cc @bakkot, maybe ecmarkup doesn't handle linking 402 AOs properly?)

• Confirming that Intl.getSupportedValuesOf is supposed to throw on a null options argument? (seems fine, just making sure)
• editorial: "The list must includes" should be "The list must include", throughout
• editorial: "list of String" should be "list of Strings"
• https://tc39.es/proposal-intl-enumeration/#sec-availablecalendars doesn't specify that the list must be unique, nor does it specify its ordering. I would hope that it's always unique, and always sorted deterministically, even if the contents of strings are defined by the host or implementation. It would also be helpful to use 262's terms for these, to indicate it's up to the host/implementation. Same feedback on all the "AvailableX" AOs.
• normative: Why do we need a "SupportedValues.prototype" object? the only purpose of its internal slot and single prototype method (Symbol.iterator) seems to be so it's an iterable object - is there a reason not to just return an iterator directly, without creating a new kind of thing?

(Feel free to check the boxes as you address the comments)

[FrankYFTang]

@ljharb I try to address all except the last about "SupportedValues.prototype" in #19

For the "SupportedValues.prototype" issue- could you show me how to "just return an iterator directly" ?

[ljharb]

Sure - String.prototype.matchAll (or entries/keys/values on Arrays/Sets/Maps) do make a custom kind of iterator, but they don't return purely an iterable. So at the least, to match that, you'd make a SupportedValuesIterator object or something, a la https://tc39.es/ecma262/#sec-createarrayiterator.

However, it seems ideal to avoid creating new iterator types, and you could call https://tc39.es/ecma262/#sec-createiteratorfromclosure with a custom "SupportedValuesIterator" brand, and %IteratorPrototype%, and it'd just be a "normal iterator", but its next method would throw when .called on any other kind of iterator.

[FrankYFTang]

Not sure I follow what you are suggesting here.
So I still need to call Return ! CreateSupportedValuesObject( list ) in the end of Intl.supportedValuesOf ( key [ , options ])

and in CreateSupportedValuesObject( list) I need to return an object which has [ @@iterator ] () to call the CreateIteratorFromClosure right? if I do not use a new iterator types, then how could I wire such [ @@iterator ] () to call the CreateIteratorFromClosure ?

[FrankYFTang]

@ljharb I merge #20 so please take a look again to see is there any more issues from your point of view.

[ljharb]

It seems like the substring stuff in https://tc39.es/proposal-intl-enumeration/#sec-iswellformedunitidentifier is a bit unclear (the “before” and “after” stuff). Not sure how to make it more precise.

is “-“ a valid collation or calendar type? What about starting or ending with a hyphen? Can the Unicode standard references be links?

Why is v1, v2, and v3 of 402? The specs have years or edition numbers, but not versions.

Other than these and #21, i think my review is concluded :-)

[FrankYFTang]

It seems like the substring stuff in https://tc39.es/proposal-intl-enumeration/#sec-iswellformedunitidentifier is a bit unclear (the “before” and “after” stuff). Not sure how to make it more precise.

is “-“ a valid collation or calendar type? What about starting or ending with a hyphen? Can the Unicode standard references be links?

The green part is what the proposal change to the ECMA 402 and the rest pre-exist in ECMA402 (see https://tc39.es/ecma402/#sec-iswellformedunitidentifier ) and I am not proposing any changes to it. The non-green part are included in this proposal just to show where the green part will be inserted into ECMA402. So I think your comments above are not related to this proposal. But rather critique to ECMA402 itself in the status quo. (which could be a valid issue but should be fixed as PR to ECMA402 instead of here)

Why is v1, v2, and v3 of 402? The specs have years or edition numbers, but not versions.

Other than these and #21, i think my review is concluded :-)

somehow that green highlighted part is ALSO in ECMA402 already and not <ins> by my proposal see. https://tc39.es/ecma402/#legacy-constructor

[ljharb]

Gotcha, thanks - typically proposal text omits entirely any AOs that are unmodified, using an invisible placeholder to ensure the numbering is correct.

Any review comments that apply to things already in 402 can, of course, be ignored here :-)

[FrankYFTang]

@ljharb I changed the spec text to return array instead of iterator to avoid the opposition in TC39. Could you take another look and tell me if you see any additional work I need before TC39. I intend to propose for Stage 3 advancement in 2021 July TC39 two weeks from now.

[ljharb]

Updated review:

• https://tc39.es/proposal-intl-enumeration/#sec-iswellformedcurrencycode step 3 says "in the range" but does not specify inclusive/exclusive on either end. Perhaps there's another way this could be written that wouldn't beg the question of boundary inclusivity? (update: i see this is already in 402, so you can ignore)

So, all looks great to me! Thanks.