Definition of {} is slightly ambiguous

[jyasskin]

We have "If the argument at index i is declared with a default value, then append to values that default value." in https://webidl.spec.whatwg.org/#dfn-overload-resolution-algorithm. When the default value is {}, the only meaning I can find is in https://webidl.spec.whatwg.org/#dfn-optional-argument-default-value

Optional argument default values can also be specified using the two token value {}, which represents a default-initialized (as if from ES null or an object with no properties) dictionary value.

Conversion from ES null is fully defined by https://webidl.spec.whatwg.org/#es-to-dictionary, but an "object with no properties"--if that means what you get by typing {} in ECMAScript--can be modified by changing Object.prototype. We should ensure this is specified so that Object.prototype doesn't affect it. A simple way to do that might be to remove "or an object with no properties" from the parenthetical, but it might be better to actually spell it out.

[bathos]

I think “as if from ES null” covers it unambiguously and that the “or an object” part would be more misleading than helpful even if “corrected.” There’s a lot more than just Object.prototype which could impact conversion behavior. Unlike conversion from ES object, conversion from ES null has no observable steps. As there are no ES-observable steps when creating a default dictionary, it should probably not mention object conversion at all.

[domenic]

The intent of that section, if I recall, was that the {} is a purely syntactic decoration that makes it clearer for readers. (See #602.) The sentence you quote was not meant to be a definition, but instead a statement about what that syntactic decoration "represents". In this context, "represents" means "how you should think about it when reading", not anything normative.

Note that "object with no properties" is mean to indicate an object with no properties, not an object which inherits its properties from Object.prototype.

Some more background can be found by digging through #750 and the linked threads.

That said, it seems like there is some gap in the normative requirements here, which fails to translate the default values {} and [] into actual ECMAScript values, of the type that you could put into the overload resolution algorithm's outputs. (Arguably, it's also not very rigorous to take the Web IDL token false and translate that into the ECMAScript boolean value false, either.) We should probably have an explicit procedure that does that conversion between value spaces.