Strong evidence for treating null and undefined the same

[ljharb]

tc39/ecma262#1069 (comment) demonstrates, convincingly to me, that instead of “ES6 default arguments distinguish undefined and null” setting a precedent, that they in fact defy it - and that this proposal (and optional chaining) should thus stick with the established precedent, continued in most of ES6, that null and undefined should be treated the same.

Thoughts?

[fatcerberus]

I would prefer that they not be treated the same. The behavior used for default parameters is ideal IMO. If I set a value to null it’s because I want it to be null, and not be reinterpreted as any other value. If it’s undefined then that means I didn’t set it and substituting a meaningful default is acceptable. In other words, I treat null as a meaningful value in its own right.

JS is in a somewhat unique place having two distinct “null-like” values, and I wouldn’t want to lose the advantages of that by having the language unilaterally treating them as the same thing.

With regard to the connection to default parameters: I’ll just say that I would intuitively expect the following two bits of code to be equivalent:

function(a = 812) {
    print(a);
}

Versus

function fn(a) {
    a = a ?? 812;
    print(a);
}

[hax]

@ljharb I think that issue only relate to iteration protocol and spread operator.

[ljharb]

@Has the issue is indeed, but the research results are broadly applicable.

[hax]

But it seems the table only cover the usage of iteration protocol (the constructor usages may be exception, but awb already explained that: tc39/ecma262#1069 (comment) )

[ljharb]

Sure. But they’re still examples of many places where the language treats null and undefined the same, which is the relevance to this proposal.

[hax]

Ok, we may need a much bigger table to collect all the behaviors...

As my understand, undefined in the language is originally used for the cases which would be static error in static type languages (eg. missing argument, return void, out of index range, no exist prop access, etc.) Except those cases, I agree its semantic should be treat same as null in most other cases.

[claudepache]

I think that the traditional use of null/undefined is not a very important thing to consider in order to decide the semantics of ??. One can find arguments one way or the other based on ideal grounds; but for practical purposes, I think it is more useful to be able to distinguish between nullish and non-nullish than between undefined and non-undefined. Consider:

• Object.getOwnPropertyDescriptor(foo).set — either a function or undefined;
• Object.getPrototypeOf(foo) — either an object or null;
• many DOM APIs return either an object of some type (e.g. a Node) or null.

In those cases you might or might not find a convincing reason why ”no value” is encoded precisely as undefined, respectively null; it doesn’t matter, because you don’t care when your goal is to provide a fallback.

Also, the two major cases I know where the distinction between undefined and null is important and indeed useful, namely JSON stringification and defaults, are situations where you provide a value, not where you get one. In those cases, it is in fact more useful to have ?? acting on both undefined and null, per #6 (comment).

[hax]

@claudepache Unfortunately, your two examples are actually the cases where the distinction of null/undefined is important, because the reverse operations will throw TypeError if not use correct null/undefined values.

Object.defineProperty(foo, 'bar', {set: v}) throws TypeError if v is null.
Object.setPrototypeOf(foo, v) throws TypeError if v is undefined.

[claudepache]

@hax Yes, the distinction between null and undefined is sometimes important. My point is: it does not follow that it is useful to treat them differently when found at the LHS of the nullish-coalescing operator.

[lostpebble]

I disagree that there are not useful use cases for distinguishing between null and undefined. I think those differences in the JavaScript world are quite important.

It basically boils down to:

• if a value is null, it is null because it has been deliberately set as null at some point
• if a value is undefined it means it is not a set value at all

Just that basic premise tells me that they are actually very different at a very base level.

In my personal use case, I use Google Cloud's Datastore as one of my data backends. Directly from their documentation (https://cloud.google.com/datastore/docs/concepts/queries#restrictions_on_queries):

Note: It is not possible to query for entities that are specifically lacking a given property. One alternative is to add the property with a null value, then filter for entities with null as the value of that property.

So this is what I do for properties which I still want to query on as being "void of value". I set them as null.

But now if I want to use the ?? operator, it is pretty much useless for me in differentiating between something which has been deliberately set, and something which is actually undefined and unset.

---

Would it not be possible to perhaps have an extra, stricter operator for the cases where matching with undefined / completely unset values is needed?

[Mouvedia]

Null values in the merge patch are given special meaning to indicate the removal of existing values in the target.

I could find many other real world examples; @lostpebble what matters are nullish coalescing common use cases.

[claudepache]

@lostpebble I agree that the difference between null and undefined is sometimes important, but it is not clear that the nullish-coalescing operator ought to be the specific tool to differentiate them.

A concrete example of code would help to understand the usefulness.

[ljharb]

@lostpebble obj.prop = undefined, there, now it's not null but it's still been explicitly set.

In other words, the convention you're talking about is merely that - a convention, and not a universal one.