Sort out when dictionaries and records should have default values

[bzbarsky]

Right now optional dictionary arguments in trailing position have a default value (empty dictionary) but other optional dictionaries (non-trailing arguments, dictionary members) do not.

This allows spec authors to create APIs in which undefined and empty dictionary have different behavior, which seems suboptimal.

So I'd like to propose that optional dictionaries always have empty dictionary as default value. What that means in practice is not clear. I guess they should use null as the default value. Sadly that's observably different from using {} if someone spews things on Object.prototype...

Anyway, if we do that, then we have one problem: dictionary-to-JS conversion can give ugly results (as described in https://bugzilla.mozilla.org/show_bug.cgi?id=1226475#c0 for example).

To solve that, I propose the following:

1. A dictionary is "elidable" (better-naming-wanted) if it is either empty or only has members whose values are themselves elidable dictionaries.
2. When converting a dictionary to a JS value, skip over members whose values are elidable dictionaries, just like we skip over members that are not present.

For dictionaries that have default values that will still cause them to appear (with those default values), but I can live with that, I think.

@domenic/@heycam Thoughts?

[bzbarsky]

Er, trying to actually get @domenic and @heycam on here, since github seems unhappy with the slash there...

[jan-ivar]

See https://bugzilla.mozilla.org/show_bug.cgi?id=1226475#c6

[domenic]

So I'd like to propose that optional dictionaries always have empty dictionary as default value. What that means in practice is not clear. I guess they should use null as the default value. Sadly that's observably different from using {} if someone spews things on Object.prototype...

Would it be possible to say something like "when an ECMAScript value is not supplied for the argument, the corresponding Web IDL value is the empty dictionary"? I don't quite understand why you need a default value.

Anyway, if we do that, then we have one problem: dictionary-to-JS conversion can give ugly results (as described in https://bugzilla.mozilla.org/show_bug.cgi?id=1226475#c0 for example).

I guess this doesn't seem like a big deal to me; having a canonical form with the same keys every time seems like a plus, even if their values are not terribly useful. But I don't feel strongly, so we can change it if you want.

For dictionaries that have default values that will still cause them to appear (with those default values), but I can live with that, I think.

Indeed, this seems like a good thing in fact.

Thoughts?

Overall sounds sane, although if there are cases where {} and undefined are treated differently, then I guess we are in trouble. It sounds like the Bugzilla comment 6 concern was aleviated in that regard though? Will we never have such a case?

[bzbarsky]

Would it be possible to say something like "when an ECMAScript value is not supplied for the
argument, the corresponding Web IDL value is the empty dictionary"?

Sure. We already say something like that that for dictionaries in trailing position, as I noted.

although if there are cases where {} and undefined are treated differently, then I guess we are in trouble

The only cases where that happens are:

1. A union which contains a dictionary and the default value is a value for one of the other types in the union. But then conversion from IDL to JS would produce that default value, not undefined.
2. If someone adds properties on Object.prototype, because undefined always produces an empty dictionary while {} would then possibly produce a nonempty one. But that would be a problem for arguments too; people should just not add properties on Object.prototype because that kills puppies.

[bzbarsky]

This needs to be sorted out for records too...

[jan-ivar]

Automatically eliding empty dictionaries might make it harder to provide invariants to JS, like:

if (pc.getParameters().rtcp.cname) // TypeError: pc.getParameters(...).rtcp is undefined

That might be correct in this particular case, but as a general rule, I could see it causing edges if a returned dictionary is non-empty most of the time (but not always).

[jan-ivar]

The workaround of marking rtcp as required, might mean we couldn't reuse the dictionary for pc.setParameters() (Again, a hypothetical example, as we might actually want rtcp to be absent until rtcp-related data is available).

[bzbarsky]

@domenic @tobie @annevk This is causing problems because specs are coming up with APIs that involve optional dictionaries that have required members: something that never works as an argument but technically works as a dictionary member right now, breaking the symmetry between "list of arguments" and "a dictionary with some members".

So we need to decide whether we want to allow breaking this symmetry and if not we need to change IDL accordingly so people stop trying to do that.

[annevk]

I think I'd argue that a dictionary member that is a dictionary should have a default value as well.

dictionary Foo { required long foo1; };
dictionary Bar { Foo myFoo; };

...
  void doStuff(optional Bar myBar);

Invoking doStuff() should throw. Invoking doStuff({ myBar: { foo1: 42 }}) would be okay, as far as IDL is concerned.

I don't think there's a good reason to make dictionary handling inconsistent between it being an argument and a member of another dictionary.

(According to bz on IRC Firefox already does this.)