Require options to be an object

[sffc]

Currently, we coerce the options argument to an object by calling ToObject. @justingrant suggested in tc39/proposal-temporal#693 that we should be stricter and throw instead.

I don't think we should change older Intl objects, due to backwards compatibility, but we can adopt this pattern in new objects.

[anba]

If there's agreement to perform this change, we should definitely also try to apply it to the existing Intl constructors. And only if we detect any web-compat issues, back it out for the affected constructors. Similar to how we managed to restrict the "IntlLegacyConstructedSymbol" hack to just Intl.NumberFormat and Intl.DateTimeFormat, but not Intl.Collator.

[ptomato]

There's a way to make this change non-normatively as well. We could change the definition of GetOption but make sure to use ToObject first on all objects passed to existing uses of GetOption. That way, the definition of GetOption could move into 262 when Temporal does, but the behaviour in Intl could remain unchanged.

I'll prepare a PR with both the editorial and normative changes, split into two commits, for discussion.

[ptomato]

OK, this is in #493, one non-normative commit followed by a normative commit.

[sffc]

Another option, which I mentioned in the meeting:

Keep GetOption defined as it is now, and move it to 262. In 262, make new abstract operations as follows:

<emu-clause id="sec-normalizeoptionsobject" aoid="NormalizeOptionsObject">
  <h1>NormalizeOptionsObject ( _options_, _legacyMode_ )</h1>
  <p>
    The abstract operation NormalizeOptionsObject massages _options_ into an Object to be subsequently passed to GetOption. _legacyMode_ should be *false* except in contexts where it is required for backwards compatibility.
  </p>
  <emu-alg>
    1. If _options_ is *undefined*, then
      1. Return ObjectCreate(*null*).
    1. If Type(_options_) is Object, then
      1. Return _options_.
    1. If _legacyMode_, then
      1. Return ToObject(_options_).
    1. Throw a *TypeError* exception.
  </emu-alg>
</emu-clause>

Change the 402 call sites as follows:

<!-- Current 4 lines, present in several places, preceding calls to GetOption -->
1. If _options_ is *undefined*, then	
  1. Let _options_ be ObjectCreate(*null*).	
1. Else,	
  1. Let _options_ be ? ToObject(_options_).

<!-- Replace with: -->
1. Let _options_ be NormalizeOptionsObject(_options_, true).

All new callers of NormalizeOptionsObject should have legacy mode disabled. We would enable it for the existing 402 call sites only so that the change is purely editorial.

@jswalden @FrankYFTang @gibson042 @leobalter

[ljharb]

Rather than adding a "legacy mode" into 262, why not have an operation in 402 that calls NormalizeOptionsObject, and if it's abrupt, wraps the original value in ToObject?

[sffc]

If we don't want the legacy mode in 262, we could do:

<!-- 262 -->
<emu-clause id="sec-normalizeoptionsobject" aoid="NormalizeOptionsObject">
  <h1>NormalizeOptionsObject ( _options_ )</h1>
  <p>
    The abstract operation NormalizeOptionsObject massages _options_ into an Object to be subsequently passed to GetOption. It throws a TypeError if _options_ is not undefined and not an Object.
  </p>
  <emu-alg>
    1. If _options_ is *undefined*, then
      1. Return ObjectCreate(*null*).
    1. If Type(_options_) is Object, then
      1. Return _options_.
    1. Throw a *TypeError* exception.
  </emu-alg>
</emu-clause>

<!-- 402 -->
<emu-clause id="sec-normalizeoptionsobjectlegacy" aoid="NormalizeOptionsObjectLegacy">
  <h1>NormalizeOptionsObjectLegacy ( _options_ )</h1>
  <p>
    The abstract operation NormalizeOptionsObjectLegacy massages _options_ into an Object to be subsequently passed to GetOption. It does not throw an exception, instead making a best-effort attempt at coercing _options_ to an Object. Newer spec code should use ECMA-262's NormalizeOptionsObject instead.
  </p>
  <emu-alg>
    1. If _options_ is *undefined*, then
      1. Return ObjectCreate(*null*).
    1. If Type(_options_) is Object, then
      1. Return _options_.
    1. Return ToObject(_options_).
  </emu-alg>
</emu-clause>

[ptomato]

NormalizeOptionsObject and NormalizeOptionsObjectLegacy seem reasonable to me. To get things moving, I would propose adding them both to the 402 spec, then we can later move NormalizeOptionsObject and GetOption into 262?

[FrankYFTang]

I support @ptomato's suggestion in #480 (comment) and @sffc proposal in #480 (comment)

[ptomato]

I've updated the PR so that it doesn't make any normative changes. Please take a look when you have time!

[sffc]

2021-02-11 discussion: https://github.com/tc39/ecma402/blob/master/meetings/notes-2021-02-11.md#require-options-to-be-an-object-480

We agreed to adopt the new stricter GetOptions behavior in newer APIs, but not to change older APIs to avoid breaking the web with what would most likely be benign errors. We should document this decision by ensuring that new constructors use the new behavior.

[ljharb]

Is it not worth some telemetry to figure out if it would break the web?

[sffc]

Is it not worth some telemetry to figure out if it would break the web?

I'd be happy if someone can volunteer to do this, but from a prioritization standpoint I don't want this to delay more urgent issues that are on our backlog.

[FrankYFTang]

2021-02-11 discussion: https://github.com/tc39/ecma402/blob/master/meetings/notes-2021-02-11.md#require-options-to-be-an-object-480

We agreed to adopt the new stricter GetOptions behavior in newer APIs, but not to change older APIs to avoid breaking the web with what would most likely be benign errors. We should document this decision by ensuring that new constructors use the new behavior.

Could you clearly define which one are part of the "newer APIs" and which one are part of the "older APIs"? The word "newer" and "older" is very ambiguous here.

[gibson042]

Any API introduced to the specification from this point forward, minus possible exceptions for anything that is already mature enough for that change itself to present a risk.

[sffc]

I filed #537 to track updating new ES 2021 proposals.

[FrankYFTang]

FYI v8 tracking https://bugs.chromium.org/p/v8/issues/detail?id=11466
test262 tracking tc39/test262#2950

[Constellation]

JSC change FYI WebKit/WebKit@51b6659

[sffc]

Given that #538 and tc39/proposal-intl-segmenter#135 are merged, is there anything remaining to do on this issue?

[gibson042]

Yes: #480 (comment)

We should document this decision by ensuring that new constructors use the new behavior.

I'm working on similar changes now, and do expect this to close soon.