Language-independent definition of interfaces should mention how to create instances

[jyasskin]

Because you have to provide a realm in order to create a new object implementing an interface, there's no way to create platform objects from a language-independent specification. The language-independent definition of Interfaces or Objects implementing interfaces should mention this and link to the text we want specs to cite when creating objects.

[bathos]

Is Web IDL meant to be “language-independent” in that sense? It supports multiple language bindings, but as far as I can tell, one of them must always be an ES binding. A lot of important parts of the spec (e.g. calculation of member exposure sets, types like Promise<T>) appear to intimately depend on the existence of an ES environment and the semantics it brings to the party, sometimes in ways that appear to have security/integrity implications.

[domenic]

I don't think it's a supported use case to create objects in a language-independent environment. There's an abstraction layer to allow multiple language bindings (in theory), but using Web IDL in an environment without a target language isn't supported or desired. (And indeed, even using it in a non-JS environment isn't really supported, although in theory it might be desired.)

The second paragraph of https://webidl.spec.whatwg.org/#introduction tries to make this clear, I think.

[jyasskin]

Right, a long time ago there was an attempt to let people use WebIDL to target more languages than just ECMAScript, but we've given up on that, and the primary remaining vestige is the division in the spec between 2 Interface definition language and 3 ECMAScript binding. It would be reasonable nowadays to merge those two sections, and doing so would probably help this issue.

But there's actually a subset of WebIDL that is language-independent (that is, could be used to target a non-ES environment), in that it's now fully defined in terms of Infra types rather than ECMAScript objects. Dictionaries, strings, numbers, sequences, unions, etc. fall into that subset, while interfaces, Promises, etc. don't. In Web specifications, I think the effect is that you can create instances of the language-independent types from 'in parallel' or generally in contexts that don't have a 'current realm', while you can only pass around references to existing language-dependent objects in those contexts.

I guess my actual point in this issue is that it should be clearer to spec authors which types fall into which subset, to make it easier to keep our cross-realm references straight. Interfaces seem to be the easiest to get confused about, but we should also be clearer about the other types.

[domenic]

I like that framing, and especially the focus on in-parallel vs. in-a-realm contexts. Agreed.

[annevk]

I'm not sure fully merging the language with the binding would be desirable given the existence of Wasm and the knowledge that implementations typically have a C++/Rust binding. Otherwise agreed.