-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New principle: When dictionary members should be nullable #446
Comments
Generally optional is indeed better than nullable. The exception is: it's natural to pass the return value of a getter to that dictionary member and the getter can return null. This is the case that applies to As for your example at the end, a required member cannot have a default value. |
As you know, if you have a dictionary
member
doesn't have to be provided when you create the dictionary, or developers can explicitly passundefined
as its value, and spec prose can use "if foo["member"] exists" to check for this situation.API designers are sometimes tempted to instead write
Then developers can pass either
null
orundefined
to mark that the field is absent, and spec prose uses "if foo["member"] is null" to detect this situation. I suspect we want to discourage spec authors from doing this, and encourage the first spelling instead. However, RequestInit.signal manually implements this pattern, which is making me second-guess that advice.Occasionally we can also have
in which absent or
undefined
produce one state, andnull
produces a different state. This is almost always confusing, but there are some rare cases that it can be helpful.I can't recall ever seeing
dictionary Foo { required SomeType? member[ = null]; }
in a proposed spec change, but it might be worth discouraging too.
The text was updated successfully, but these errors were encountered: