Note that this will require a ton of spec updates, by the way, to add all the now-required = {}.

Created PRs for whatwg/dom#771 and whatwg/html#4745. This will require Bikeshed changes too, tracked at speced/bikeshed#1491 and plinss/widlparser#39 for the IDL parser backend.

My first thought was to use = null

Mine was too, and is in fact what Gecko has long implemented, but @annevk convinced me that this is more what people are likely to expect.

@annevk thank you for filing all those!

https://bugzilla.mozilla.org/show_bug.cgi?id=1562680 tracks Gecko implementing this.

We probably need to get a bunch of other spec issues filed... Can we hope the bikeshed changes will drive that, or should we go through the list of changes I needed to make to IDLs in Gecko and try to file issues based on that?

If you can dump a file list in a new issue for triage that'd be good I think. The other problem with updating IDL in the specifications is that we also need testharness support as it automatically gets the IDL from the specifications.

webidl2.js is fixed in w3c/webidl2.js#338, but the copy in wpt isn't updated yet.

Just recording that the relevant bug on the Blink side is: https://bugs.chromium.org/p/chromium/issues/detail?id=948139

Do we know if the WebKit folks are aware of this change?

In both webidl2.js and bikeshed right now, this code is accepted:

dictionary A {
  required long x;
};

dictionary B {
  A a = {};
};

but it seems like this ought to be invalid since {} is not a valid A. = null seems like it should equally not work.

Semi-related, I'm not sure I know what dictionary C { A a; } means. Does this allow a to be "A or undefined"? It seems that way in Chrome's bindings generator right now. We want it to work this way if possible in WebGPU. [edit: here]

gpuweb/gpuweb#420

but it seems like this ought to be invalid since {} is not a valid A

That would be an option, yes.

= null seems like it should equally not work.

Per spec that does not work, right.

Does this allow a to be "A or undefined"?

It allows a to be not present (that is the Get() on the JS object returns undefined), but if it's present (any other value is returned) then it only allows values that can be converted to A without failing.

Chrome's bindings generator has all sorts of bugs around dictionaries, so I wouldn't base too much on what it does, but the desire for the dictionary C { A a; } case where A has required members and allowing {} to be passed for a C instance was present in a number of specs, so the IDL spec explicitly allows that.

That's really helpful, thanks for the info!

= null seems like it should equally not work.

Per spec that does not work, right.

(fwiw, webidl2.js and bikeshed do allow this, too.)

(fwiw, webidl2.js and bikeshed do allow this, too.)

I neither wouldn't base too much on what they allow, because both have been just parsers without semantics checks, while only recently webidl2.js started providing some.

@cdumez

(fwiw, webidl2.js and bikeshed do allow this, too.)

Right, it arguably used to be OK (and was supported in Gecko) until the changes in this PR. At this point it's clearly not OK, though. IDL null (not to be confused with JS null!) is not a valid value for a dictionary type.