New principle: When dictionary members should be nullable

[jyasskin]

As you know, if you have a dictionary

dictionary Foo {
  SomeType member;
}

member doesn't have to be provided when you create the dictionary, or developers can explicitly pass undefined 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

dictionary Foo {
  SomeType? member = null;
}

Then developers can pass either null or undefined 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

dictionary Foo {
  SomeType? member;
}

in which absent or undefined produce one state, and null 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.

[annevk]

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 RequestInit. And the reason it doesn't default is because we don't want to override the first argument of the Request constructor when that is a Request object. So undefined and null indeed mean different things here.

---

As for your example at the end, a required member cannot have a default value.