Re: [heycam/webidl] A non-optional dictionary argument makes sense at times. (#130)

> I don't think requiring at least one member would even help that much since we'd still have to check it's one of the members that can be supplied standalone

I'm not exactly sure what you mean (but I take it you mean "the logic of when it's a TypeError is non-trivial"). That shouldn't matter... all that matters is: "is it a TypeError in the case where you pass `{}`?". If the answer is "yes", then I think this rule shouldn't apply. Given that the spec itself states that "This is to encourage API designs that do not require authors to pass an empty dictionary value when they wish only to use the dictionary’s default values," I feel it shouldn't apply in a case where authors are explicitly forbidden from using the dictionary's default values.

> It's very much a special case

It is (though we now have at least 2 examples). But it's not like we are writing a special case in code that's going to need extra edge cases, tests, etc, in an implementation. This isn't a spec, it's a meta-spec. It should give us (as spec authors) the tools to do our work, and guidelines on how to do it well, not constrain us when we hit a special case.

> You might want to point it out in a note though.

I've got a note about this in [Web Share](https://wicg.github.io/web-share/#navigator-interface). I was hoping to remove it though :)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/130#issuecomment-313046684