Re: [heycam/webidl] State that by default all objects are created in the relevant realm of `this` (#135)

@annevk tried tackling this again recently. Some discussion in https://freenode.logbot.info/whatwg/20210203#c6775366 .

Here's one proposal, motivated largely by the fact that we still haven't solved this. (So, my previous appetite for making things explicit is dampened.)

- Goal: all interfaces are created in "the relevant realm"*. This is motivated by:
  - Some of the caching-related arguments above, plus
  - The fact that browsers seem to do this [at least in some cases](https://wpt.fyi/results/WebIDL/current-realm.html?label=master&label=experimental&aligned) and we don't want to create potentially compat-impacting churn.
- Goal: all promises, exceptions, dictionaries (`Object`s), sequences (`Array`s), records (`Object`s), iterator results, ... are created in "the current realm"*. This is motivated by:
  - Browsers seem to do this for exceptions, and for at least synchronously-rejected promises.
  - The IDL spec seems to implicitly do this for many cases, such as synchronously-rejected promises, sequences, records, and dictionaries.
  - This is the automatic default whenever we use ES spec machinery, e.g. %% notation or CreateIterResultObject, and overriding it would be quite annoying.
- Goal: spec authors don't need to know the above two rules.
- Stretch goal: spec authors almost never need to explicitly specify a realm.

(*): what does "the current realm" and "the relevant realm" mean when you're inside a queued task? We want to formalize its intuitive meaning: whatever the current/relevant realm was when the original main-thread task kicked off.

Proposal:

- We define "general creation realm" and "interface creation realm" as IDL/HTML-maintained concepts. These correspond, respectively, to the current and relevant realms, but they work even in queued tasks.
  - For the sync body of regular methods and accessors, these are equal to the current/relevant realms, respectively.
  - For the sync body of static methods and constructors, these are both equal to the current realm.
  - Going "in parallel" stores the "general creation realm" and "interface creation realm" in some ambient per-in-parallel-invocation thingy.
  - Queueing a task grabs the "general creation realm" and "interface creation realm" from the ambient in-parallel invocation, and restores them.
    - For "queue a global task" should the global passed have any impact? I think no, although analyzing some cases where it conflicts might be interesting.

- We update "new" for interfaces to use the interface creation realm, unless overridden. (Do we even want to allow overrides?)

- We update "convert" for dictionaries/sequences/records to use the general creation realm.

- We update "throw" and "create" for exceptions to use the general creation realm.

- We update "a new promise", "a promise resolved with", "a promise rejected with", and "get a promise for waiting for all" to use the general creation realm.

- We update the conversion of throws into rejected promises to use the general creation realm (or just the current realm).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/135#issuecomment-772716243