Reconsider advice to leave dictionary members optional when dictionary is used solely as a return type

[weinig]

What is the issue with the Web IDL Standard?

The WebIDL spec currently gives this advice for specification authors:

Note that specifying dictionary members as required only has an observable effect when converting other representations of dictionaries (like a JavaScript value supplied as an argument to an operation) to an IDL dictionary. Specification authors should leave the members optional in all other cases, including when a dictionary type is used solely as the return type of operations.

I think think this advice should be reconsidered, as even in the case of dictionary that is used solely as a return type, it can be useful for clients of the dictionary (authors writing web pages) to know which members of the dictionary will always be present, without having to delve into the prose. This allows them to avoid things like unnecessary undefined checks.

It also has a nice side benefit of allowing engines to optimize their internal representations more easily.

[annevk]

#842 touches upon this and I think there are other existing issues. Generally @domenic has been quite opposed to making return types more specific.

I think I favor being more specific now. It has a very clear benefit to code generation and it also documents the possible states a dictionary can be in a lot better. No need for anyone reading it to have to consider the "is missing" case is good.

(We can workaround this on the implementation side with [ImplementationRequired] and similar annotations, but this does not help other readers of the specification.)