JavaScript undefined replaced with null

Question

In JavaScript undefined can be reassigned, so it is often advised to create a self executing function that assures undefined is actually undefined. As an alternative null and undefined are definitely == but are any other values loosely equivalent to null/undefined?

TLDR

Basically can you safely replace this:

(function(undefined){

   window.f = function(obj){
     if(obj===undefined || obj===null ){
       alert('value is undefined or null');
     }
   }

})();

with:

window.f = function(obj){
  if(obj==null){
    alert('value is undefined or null');
  }
}

If the above is 100% safe, why doesn't the JavaScript community/libraries drop undefined altogether and use the shorter x == null conditional to check for both null/undefined at once?

EDIT:

I have never seen someone actually represent an "unknown value" with 'undefined' vs null? I have never seen this scenario, and is why I originally asked the question. It just appears to be two incredibly confused values that are never used in their original intent. Standardizing everything to do a comparison obj==null would be beneficial for size and avoid any issues with reassignment. Everything would continue to work

var obj={};
obj.nonExistantProperty==null // true

var x;
ix==null // true

function(obj){
  obj==null // true
}

The one exception to this rule appears to be when casting undefined/null to an integer. This is a pretty age case scenario, but definitely should be noted.

+(null)==0 while isNaN(+undefined)

Considering NaN is the only value in JavaScript not equal to itself, you can do some pretty crazy things like:

+undefined == +undefined // false
+null == +null // true

Using null as a loose equality == drop in replacement for undefined is safe, provided you don't plan to cast the value to an integer. Which is a pretty edge case scenario.

Solution 1

The abstract equality algorithm from section 11.9.3 of the language spec is what defined == and != and it defines them such that

null == void 0
null == null
void 0 == null

where void 0 is just a reliable way of saying undefined (see below) so the answer to your question is yes, null is equal to undefined and itself and nothing else.

The relevant parts of the spec are

1. If Type(x) is the same as Type(y), then
     If Type(x) is Undefined, return true.
     If Type(x) is Null, return true.
     ...
2. If x is null and y is undefined, return true.
3. If x is undefined and y is null, return true.
...

If you're worried about undefined meaning something other than what it normally means, use void 0 instead.

null               ==  void 0           // True
({}).x             === void 0           // True
"undefined"        === typeof void 0    // True
(function () {})() === void 0           // True
(undefined = 42,
 undefined         === void 0)          // False
"undefined"        === typeof undefined // False
"undefined"        === typeof void 0    // True

From the language specification:

11.4.2 The void Operator

The production UnaryExpression : void UnaryExpression is evaluated as follows:

1. Let expr be the result of evaluating UnaryExpression/.
2. Call GetValue(expr).
3. Return undefined.

So the void prefix operator evaluates its argument and returns the special value undefined regardless of to what the global variable undefined has been changed (or whether undefined is defined :).

EDIT: In response to comments,

If you are dealing with library code that distinguishes between the two, then you need to deal with the difference. Some of the new libraries standardized by the language committee do ignore the difference : JSON.stringify([void 0]) === "[null]" but there is too much code out there that treats them subtly differently, and there are other differences :

+(null) === 0
isNaN(+undefined)

"" + null === "null"
"" + undefined === "undefined"

If you're writing any kinds of libraries that produce text or serialize/deserialize and you want to conflate the two then you can't pass undefined through and expect it to behave as null -- you need to explicitly normalize your inputs to one or the other.

Solution 2

Because of this:

var myVar1;
var myVar2 = null;

if (myVar1 === null) alert('myVar1 is null');
if (myVar1 === undefined) alert('myVar1 is undefined');
if (myVar2 === null) alert('myVar2 is null');
if (myVar2 === undefined) alert('myVar2 is undefined');

Anything set to null is not undefined - it's defined as null.

Comments

[Lime]

My point is there appears to be no value in distinguishing between the two. Although undefined is supposed to represent an "unkown value", nobody actually holds to this convention.

[Brian]

Assuming you never assign anything to a value of undefined, there's value in being able to differentiate between an untouched variable and a nullified one. Though, for all pratical purposes in how JS is used by developers today, I can see your point...

[Lime]

You could just as easily use null in the code above as using void 0. I could also argue that null is slightly easier to read and type then void 0. My point is there appears to be no value in distinguishing between the two. Although undefined is supposed to represent an "unkown value", nobody actually holds to this convention. So it would appear beneficial to ignore undefined every existed and just use obj==null in its place.

[Lime]

Thanks, I wasn't aware of what the values were when casted to integers. Having NaN vs 0 is definitely different. It appears [null].join('') and [undefined].join('') are equivalent though.

[Lime]

The last one is horrendous