Is nullable dictionary member a footgun?

[saschanaz]

What is the issue with the Web IDL Standard?

whatwg/fs#181

Somehow the File System specification made all optional dictionary members nullable while never expecting them to be null, and then somehow no implementers filed a spec issue and went ahead dealing with null.

I wonder how many nullable dictionary members are out there and how intentional they are. I certainly think this is not the first case where someone just put nullable into dictionary member without knowing that the optionality is implied. I can make and run some linter in webidl2.js...

[annevk]

A member of a dictionary being nullable is sometimes needed, because people expect to be able to pass in an object of the same shape for instance, which has getters that return null. I don't think it's needed in the FS case though.

Perhaps we should require an attribute for the "object-of-the-same-shape" type though and try to outlaw it in the normal case.

[saschanaz]

Perhaps we should require an attribute for the "object-of-the-same-shape" type though and try to outlaw it in the normal case.

I wonder whether we would want to automate that:

interface FooInt { /* ... */ };
dictionary FooDict : FooInt {}; // Implicitly gets all attributes of the interface?

[annevk]

Not sure that would work. Request has this property as an example.