Editorial: Add notes about extension points for ECMA-402

[ptomato]

As per TC39 plenary, the specification should include informative notes indicating where ECMA-402 extends prototypes with additional properties.

Closes: #2169

[ljharb]

I'm confused. Does this mean that era/eraYear will remain absent from 262?

It wasn't clear on the agenda that consensus was being asked for something, or I'd have attempted to attend that session - I don't find that an acceptable outcome, if so.

[codecov]

Codecov Report

Merging #2442 (9e96f49) into main (140885e) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #2442   +/-   ##
=======================================
  Coverage   94.65%   94.65%           
=======================================
  Files          20       20           
  Lines       11152    11152           
  Branches     1979     1979           
=======================================
  Hits        10556    10556           
  Misses        548      548           
  Partials       48       48           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[gibson042]

I'm confused. Does this mean that era/eraYear will remain absent from 262? … I don't find that an acceptable outcome

Yes, that was the outcome per discussion following presentation of the slides. Can you elaborate on why you would be unhappy with ECMA-262 indicating in its definition of an object that an implementation also supporting ECMA-402 will include properties on it that are defined in that specification?

[sffc]

I agree with @ljharb in that the conclusion from this particular issue in plenary is that we are permitted to do this, not that we should do it for era/eraYear in particular. I think we should, but this should go up separately as part of the next round of Temporal updates.

[gibson042]

@sffc Yes, thank you for sharing that clarification. I agree on all counts.

[ljharb]

@gibson042 because I think it's very unacceptable for 402 to arbitrarily add properties to existing builtins. The mechanism 402 has always had for adding on to 262 is "Intl, or replacing designated implementations" like toLocaleString. That's what I want to continue.

[gibson042]

If ECMA-262 explicitly indicates for an object that an implementation also supporting ECMA-402 will include properties on it that are defined in that specification, then the additions are by definition not arbitrary. I understand that you would be unhappy with that arrangement, and am asking for an elaboration on why. What trouble or potential trouble would be caused by ECMA-262 defining a base collection of properties for an object and delegating to ECMA-402 the definition of others that are relevant only to capabilities theirselves defined in ECMA-402?

For what it's worth, I do share your discomfort with having ECMA-402 alter the primordial shape of anything in ECMA-262 beyond the addition of an "Intl" property to the global object—but I can't articulate a specific negative consequence, and the identified alternatives all seem worse to me.

[ljharb]

The more concrete consequence I have in mind is that a universal polyfill - that thus can't assume the presence of Intl - has no fallback behavior to provide for those mechanisms like it does for toLocaleString.

[gibson042]

I don't think I understand... if the polyfill supports only the "iso8601" calendar then it would not need to provide the ECMA-402 fields at all, but if it supports any calendar for which they are relevant (such as "gregorian") then it would need to provide them. And a similar approach would be necessary even if the fields were defined in ECMA-262 with e.g. static undefined value, because ECMA-402 operations such as CalendarDateMergeFields must utilize them.

[ptomato]

@ljharb, could you say more about this universal polyfill use case? I'm not familiar with the term. I suspect there might not actually be a disagreement here, but let's dig into it to find out.

[ljharb]

@ptomato i mean one that works in any JS compliant engine, which need not contain Intl, since 402 is optional.

[sffc]

It's harmless for a polyfill to have era and eraYear getters (and possible future cycle, yearAnimal, ...) that return undefind if the calendar lacks those fields. I believe that is currently what the spec says should happen if you implement e.g. a custom calendar that doesn't implement those fields.

[ljharb]

@sffc it is very much not harmless for a polyfill to add something that’s not explicitly in the spec, and has caused problems in the past.

[sffc]

What if we said "implementations can add more accessors that defer to the calendar function of the same name, including those required by other specifications such as ECMA-402"

[sffc]

Related: is it still admissible for 262 implementations to add their own built-in calendars?

[ljharb]

Implementations already have the unlimited ability to add whatever they want - that's not the same thing as it being OK for polyfills to do it. For a polyfill to add it, the spec has to require it.

[gibson042]

@ptomato i mean one that works in any JS compliant engine, which need not contain Intl, since 402 is optional.

But also trivially detectable via typeof Intl/globalThis.Intl/etc.

[ljharb]

@gibson042 absolutely, and in the presence of Intl, i'd leverage it to do what 402 does, but I'd not want the shape of the polyfilled builtins to differ based on the presence of 402 (just like how toLocaleString currently works)

[ptomato]

To me it sounds like it comes down to whether the polyfill is going to provide any non-ISO calendars even if Intl isn't there to provide them. If it does, even just the "gregory" calendar, then you should have era and eraYear.

[ljharb]

It wouldn't provide anything that isn't in 262, in the absence of Intl.

[ptomato]

But, 262 in the absence of Intl may choose to provide non-ISO calendars, so a universal polyfill could as well.

[ljharb]

Sure, and that can be explored when a proposal is adding a new non-Intl non-ISO calendar - but unless Temporal is doing that, then that's not the reality at this time.

[ptomato]

I assume #2472 (comment) applies here as well; ECMA-262 continues to not mention era/eraYear.