Re: [heycam/webidl] Dictionary types being nullable doesn't make sense (#967)

> Is (DOMString? or MyDict) disallowed as well? I guess it should be?

Already disallowed, check the paragraph a little below the list at <https://heycam.github.io/webidl/#dfn-number-of-nullable-member-types>:

> The number of nullable member types of a union type must be 0 or 1, and if it is 1 then the union type must also not have a dictionary type in its flattened member types.

> That's only if the union type does not include a nullable type, due to step 1:

Ahhhh, I'd skipped over that somehow, right. So while the set of input values accepted is identical, the IDL value that comes out of the conversion is different.  I don't *think* there's a great reason to change that, particularly if there's any existing specs depending on it.

Okay, so my real concern is just making the rules consistent rather than arbitrary (so I can write parallel consistent rules for `undefined`); I don't much care which side of the line we land on. So instead, then, I suggest we just allow dictionaries in nullable unions.

That is, taking the cases mentioned earlier:

* MyDict: allowed today, will still be allowed, JS `null` gives default dict
* MyDict?: allowed today, will still be allowed, JS `null` gives IDL null
* (DOMString or MyDict): allowed today, will still be allowed, JS `null` gives default dict
* (DOMString or MyDict?): allowed today, will still be allowed, JS `null` gives IDL null
* (DOMString or MyDict)?: disallowed today, will be allowed, JS `null` gives IDL null
* (DOMString? or MyDict): disallowed today, will still be disallowed

-- 
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/967#issuecomment-799603847