Treating `null` as undefined as well

[Sven Slootweg]

The following is a brief summary of a discussion that was had on IRC.

I feel that when considering whether something is 'defined', it should treat null in the same way as undefined; in the current proposal, it treats null as a defined value. Given the following points:

1. It's undesirable to introduce two operators for the different cases ("only ignore undefined" vs. "ignore undefined and null"), as this would introduce confusion and possibly make it easy for readers to misinterpret what a given piece of code is doing.
2. An "escape hatch" will be needed; either of the two cases needs to be representable, but only one of the cases can have an operator assigned to it. Therefore, the other case needs to have a different, reasonably ergonomic, non-operator representation.
3. Operators are expensive to introduce (there are only a few possibilities in terms of characters used), and cheap to use (not a lot of work to read and write, and easily recognizable); therefore, the operator should be used for the common case. This maximizes the benefit that the developer gets from the use of a relatively scarce operator 'slot'.
4. In the JavaScript ecosystem, the bulk of libraries treat null and undefined interchangeably; libraries often don't even document which they will return, some of them return either of them inconsistently, and so on. In practice, this means that as a consumer of third-party code, "handling null and undefined as equivalent" is a common case.
5. It's extremely rare to run into cases where there is a meaningful technical distinction between null and undefined. In almost all cases where there is a distinction, either only one of them is ever used (but it could be either one), or the distinction is purely philosophical (eg. explicitly vs unintentionally empty value) and has no effect on real-world code that's written around it.

... it would seem logical to change the meaning of the ?| to include both null and undefined.

To rehash which cases this covers:

• null and undefined used interchangeably (common): Covered.
• Only null or only undefined used, but not both (common): Covered.
• Philosophical difference between null and undefined, but no practical consequences (uncommon): Covered.
• Meaningful technical difference between null and undefined, where both options need different treatment in consuming code (uncommon): Not covered.

This leaves the question of the 'escape hatch' - if a developer does need to express an explicit check for undefined that doesn't include null, how can they represent this? The obvious solution to this seems to be to use the proposed 'decider' mechanism (for which I have some separate suggestions for improvement).

[M.K.]

Thanks for summarizing! Everyone, feel free to vote on the suggestion with thumbs up/down emoji.

On the theoretical side, it might be nice to distinguish any existing property of a JSON container from a missing one, e.g.

let systemConfig = require('/etc/foo.json');
let localConfig  = require('./foo.cfg.json');
function worldsBestJsonValue() {
  v = (systemConfig.bestJsonValue ?| localConfig.bestJsonValue);
  if (v === undefined) { throw new Error('no idea'); }
  return v;
}

[M.K.]

Just found the Null Coalescing proposal. Link is now in the readme, too.