Make allocation of new JS objects in StructuredSerialize more rigorous

[domenic]

This spins off from tc39/ecma262#418.

Currently we say "a new X object in targetRealm". To rigorize this, I suggest defining either the prose phrase a default-constructed JS X object in targetRealm or an abstract operation ConstructJSIntrinsic("name", targetRealm) which does the following steps:

1. Let constructor be targetRealm.[[Intrinsics]].[[%X%]].
2. Return ? Construct(constructor, « »).

This could be located in our https://html.spec.whatwg.org/#dependencies JavaScript section, or in the structured serialization section. It should not be exported for other specs.

Alternately it should perhaps be located in Web IDL?

Then we can use this to replace all our "a new X object in targetRealm", linking to its definition.

[annevk]

Does IDL allocate JavaScript objects other than Array currently? Also, shouldn't JavaScript host this definition itself? Won't they need it with the Realms API if that makes it through?

[domenic]

Does IDL allocate JavaScript objects other than Array currently?

Well, it does ObjectCreate(%ObjectPrototype%) a lot, but that's easy. I guess it also uses backing Map objects, currently via the imprecise wording "... must have a [[BackingMap]] internal slot, which is initially set to a newly created Map object." So it would probably benefit.

Also, shouldn't JavaScript host this definition itself? Won't they need it with the Realms API if that makes it through?

I can't see why the realms API would need this. This is only necessary if specs need to default-construct objects themselves, which seems useful for the platform but rare for the JS spec.