Darien Maillet Valentine

Yes — it’s the common naming that makes it a footgun from my POV if they behave differently, not the different behavior itself.

It seems like both the union conversion & overload resolution algorithms would already behave sensibly if a dot were added to that grid as both have `if IsCallable(V) and there’s...

> and keeping the current logic whereby the IsCallable check happens before the dictionary conversion That’s what I’d expect — the same “fall through” pattern as sequence vs dictionary (or...

I was in favor of the accessor for consistency with `message` (and `stack` in SpiderMonkey) + the unusualness of Web IDL constructs defining own data properties, but @ljharb’s explanation changed...

> I think Web IDL generally doesn't try hard to distinguish between explicit undefined and nonexistence (e.g. dictionaries treat explicit undefined as nonexistent), and I believe nobody complained with it....

Possibly notable: ```js console.log("cause" in new WebAssembly.CompileError("xxx", {})); console.log("cause" in new WebAssembly.CompileError("xxx", { cause: 1 })); ``` already prints `false` and `true` in both Chromium & FF.

@TimothyGu Oh wow — I (think I) remember reading about that [[Prototype]]-swap-on-adoption behavior a long time ago (in spec text I think? was it specified at one point?). It looks...

I notice the [record\ conversion](https://webidl.spec.whatwg.org/#es-record) isn’t changed here yet. That’s probably just because it’s a work in progress, but it would be funny if we couldn’t use em for that,...

Another missing conversion is [`any`](https://webidl.spec.whatwg.org/#es-any). This one seems important because adding a new ES language type would cause it to have undefined behavior. The defined behavior could be to throw...

> one possible way of accomplishing the resolution of the deserializer is to use a registry in the form of an Event on the MessagePort In the browser, structured clone...