Update "Conformance" section for new options/constructors

[anba]

trafficstars

https://tc39.es/ecma402/#conformance lists which options are allowed to have implementation-defined behaviour. This section hasn't been kept up to date:

• NumberFormat: "notation", "compactDisplay", "signDisplay", "currencySign", and "unitDisplay" are missing
• PluralRules: Add the same exceptions for "minimumIntegerDigits", "minimumFractionDigits", "maximumFractionDigits", "minimumSignificantDigits" as already present for NumberFormat
• PluralRules: "type" option is missing
• RelativeTimeFormat: "style" and "numeric" options are missing

[sffc]

Appendix A has the list of implementation-depedent locale data: https://tc39.es/ecma402/#annex-implementation-dependent-behaviour

I don't know if we want to keep adding things to Section 2 that don't throw RangeError. Many of the newest features were written such that browsers would be more consistent, instead of creating a situation like "Chrome supports this other option, so that becomes web reality".

[anba]

If we can agree to remove all extensions listed in Section 2 which aren't actually used by any implementation, I'm certainly up to it.

I don't know the motivation for Section 2, maybe it was added to match the previous extension from "16 Error Handling and Language Extensions":

An implementation may define behaviour other than throwing RangeError for toFixed, toExponential, and toPrecision when the fractionDigits or precision argument is outside the specified range.

That one was removed in tc39/ecma262#857.

[leobalter]

If we can agree to remove all extensions listed in Section 2 which aren't actually used by any implementation, I'm certainly up to it.

Can we specifically flag what are those not being currently used by any implementation?

[sffc]

July 9 discussion: https://github.com/tc39/ecma402/blob/master/meetings/notes-2020-07-09.md#update-conformance-section-for-new-optionsconstructors-467

@leobalter was going to reach out to @caridy for more information on the back story of this section of the spec.

[caridy]

I believe that predates my time as editor, probably from the dates of the word doc, we can validate this by looking at first or second editions. I do agree with the sentiment here though. If new features are not throwing RangeErrors, they don't need to be listed there.

[sffc]

@norbertlindenberg @rwaldron Could you share some insight on the back story for Section 2 "Conformance" in the 402 spec? Why does it exist? What would be the consequences of the following three outcomes:

1. Continue adding items to Section 2 that could throw RangeErrors.
2. Keep Section 2 stable without adding new options to it.
3. Remove items from Section 2 to make conformance requirements stricter.

Also CC @litherum, who's been an advocate for stricter conformance requirements.

[rwaldron]

Hi! That section predates my term as editor.

[NorbertLindenberg]

This section was inspired by the Conformance section in ECMA-262. The idea was that the standard defines the minimal set of functionality, while implementations are allowed to extend the functionality. The RangeError statements came in because ECMA-402 methods often throw RangeError when they don’t recognize a property value, so allowing them not to throw the RangeError is equivalent to allowing them to recognize additional property values.

At the time, the thinking was that implementations should have significant freedom to experiment and enhance. To what extent that’s still appropriate today is up to today’s TC39 to decide.

[sffc]

This was discussed on 2020-08-13: https://github.com/tc39/ecma402/blob/master/meetings/notes-2020-08-13.md#update-conformance-section-for-new-optionsconstructors

We didn't reach a clear consensus, but I think the path forward on this ticket is to verify that Section 2 is up-to-date and self-consistent. Each individual property should be handled on a case-by-case basis.