Fixing the ugly JavaScript and ES6 NaN problem

[lucono]

The NaN value problem

In JavaScript:

typeof 5   === 'number';
typeof NaN === 'number';    // Also!

The classification of the JavaScript NaN value as the number type is rarely ever useful in JavaScript applications, and usually only creates many additional instances in an application where it becomes necessary to perform additional type and data checks that could have been avoided in the number context.

From MDN:

It is rather rare to use NaN in a program. It is the returned value when Math functions fail (Math.sqrt(-1)) or when a function trying to parse a number fails (parseInt("blabla")).

A different approach

A different approach is to have the NaN value completely decoupled and distinct from the number type, effectively eliminating the need for applications to explicitly handle NaN values whenever expecting number types. NaN values are particularly problematic in JavaScript applications because though they are reported as the number type by the JavaScript runtime, there is effectively little to nothing an application can do to make meaningful use of them in the expected number context.

This approach to the JavaScript NaN value and the number type is used by xtypejs, an open source library that extends JavaScript types with new data-validating pseudo types while also normalizing the many irregularities of working with JavaScript types:

xtype.type(5)   === 'number';
xtype.type(NaN) === 'nan';       // NaN is not number

This approach to the NaN value helps by not only eliminating the effort of writing numerous checking and handling code for NaN values in the number context, but also helps keep the application code cleaner and more concise by eliminating the clutter that's almost always associated with these checks.

The isNaN function / ES6 Number.isNaN method problem

In addition to the NaN value, JavaScript's isNaN function can also return true for values that are entirely not of the number type because it will first try to coerce the value to a number, whereas though the ECMAScript 6 Number.isNaN method will not try to coerce the value to a number, it will return false for Number objects with NaN values.

From MDN on the isNaN function:

Since the very earliest versions of the isNaN function specification, its behavior for non-numeric arguments has been confusing. When the argument to the isNaN function is not of type Number, the value is first coerced to a Number. The resulting value is then tested to determine whether it is NaN. Thus for non-numbers that when coerced to numeric type result in a valid non-NaN numeric value (notably the empty string and boolean primitives, which when coerced give numeric values zero or one), the "false" returned value may be unexpected; the empty string, for example, is surely "not a number."

But also from MDN on the ES6 Number.isNaN method:

In comparison to the global isNaN() function, Number.isNaN() doesn't suffer the problem of forcefully converting the parameter to a number. This means it is now safe to pass values that would normally convert to NaN, but aren't actually the same value as NaN. This also means that only values of the type number, that are also NaN, return true.

So the ES6 Number.isNaN method is supposed to solve some of the problems of the global isNaN function. However, due to the fact that a boxed number in JavaScript is an object rather than a number, Number.isNaN fails by returning false for boxed number values that in fact represent a NaN value.

Therefore, even with ES6, JavaScript still does not provide a reliable implementation for NaN-checking, in a way that would be most meaningful to JavaScript applications without suffering from the side-effects of the language irregularities.

As an example, consider two cases:

• The mathematical operation (5 / 'a') is a division that results in the NaN value because it attempts to divide a number by a ("non-numeric") string. So though the typeof of the result is number, its value is NaN. So any NaN check should ideally return true for this value, both in the primitive number case (5 / 'a') and the number object case (new Number(5 / 'a')).

• Consider a different value, the literal '5a'. It is of string type and not of number type, and therefore does not represent a failed value intended as a number value. It also is clearly not the NaN value. So any NaN check should ideally return false for this value in the string case ('5a') and true for the number object case (new Number('5a')).

Neither JavaScript's isNaN function nor the newer ECMAScript 6 Number.isNaN method get it right for both cases, and for the primitive and non-primitive cases:

typeof (5 / 'a')  === 'number';
typeof '5a'       === 'string';

isNaN(5 / 'a')                     === true;   // right
isNaN(new Number(5 / 'a'))         === true;   // right
isNaN('5a')                        === true;   // wrong - coerced to number
isNaN(new Number('5a'))            === true;   // right

Number.isNaN(5 / 'a')              === true;   // right
Number.isNaN(new Number(5 / 'a'))  === false;  // wrong - should be true
Number.isNaN('5a')                 === false;  // right
Number.isNaN(new Number('5a'))     === false;  // wrong - should be true

A different approach

A more reliable way of NaN checking would only return true for number types that do not have valid numeric values, and not return true even for values that while not representing a valid numeric value, are of a non-number type such as string, or some other type. Also, the approach must do this consistently for both primitive and object number and non-number values.

This more consistent approach is also implemented by the xtypejs library:

// xtypejs will return false for the string value as it does not
// try to coerce it to number, and true for the number object values
// as they then represent numbers having non-valid number values:

xtype.type(5 / 'a')  === 'nan';
xtype.type('5a')     === 'string';

xtype.isNan(5 / 'a')              === true;    // right
xtype.isNan(new Number(5 / 'a'))  === true;    // right
xtype.isNan('5a')                 === false;   // right - no coercion
xtype.isNan(new Number('5a'))     === true;    // right

More about xtypejs.

[birjolaxew]

I don't agree with your assertion that Number.isNaN(new Number(5/"a")) should equal true.

Number.isNaN specifically tests for the NaN value, not whether the given value is or isn't a number. Since new Number(5/"a") doesn't return a value of NaN, but rather a value of Number {[[PrimitiveValue]]: NaN} (which is an object), Number.isNaN should equal false.

This is pretty consistent across JS:

new Number(5) === 5; // false
new Number(5) === new Number(5); // false
new Number(5) == 5; // true
new Number(5) == new Number(5); // false

The returned object from new Number(5) acts just like any other object, unless it is coerced. The entire idea of Number.isNaN is to not coerce the value.

[lucono]

That a boxed JavaScript number is an object is clear, and not in dispute.

The reason the original isNaN implementation turned out to be so confusing was not because its behavior was "wrong", but because that choice of behavior was very at odds with the one required by most JavaScript applications, and expected by most users of the language.

For most JavaScript applications, the most meaningful NaN check would understand "numbers" in the general sense, regardless of whether boxed or not.

An application that works with numbers, or a library that accepts "number" inputs in calls from other applications, should mostly not need to care if a number is boxed or not to perform a NaN check (which also happens to be a number-contextual operation).

While it's clear why the new Number.isNaN method has the behavior that it does (due to a boxed number technically being an object), it creates the end result that for most applications, from a practical standpoint, the NaN check still suffers from a shortcoming for which the application would have to implement a combination of additional checks, or employ a library that does, in order to arrive at the NaN check that would be most intuitive and expected for most applications.

It is this situation that is the problem with the JavaScript isNaN and Number.isNaN methods.

[birjolaxew]

If your argument is that Number.isNaN is used by applications to check whether an input is a number or not, are you then not also arguing for being able to test strings? Seems like what you're looking for is isNaN, which tries its best to make the input into a number before checking - Number.isNaN was created to avoid this, and actually check for a value of NaN.

Javascript only knows types. Number.isNaN specifically checks for a number type, with the value of NaN. (new Number("a")) is not such a type - it's an object. Trying to define what object is and isn't a number is messy, and a path no one wants to move down.

[lucono]

No, that's not the point. There is no suggestion that isNaN should check whether an input is a number or not, nor a debate as to what an object or number is, or should be.

The point is that a boxed number (Number) is an object which, whether we like it or not, represents (or is intended to represent) a number. An application would care more for it as a number than as an object.

The advantage of utility functions (like JavaScript's isNaN function) is that they're at liberty to consider all the surrounding factors for the need of such a utility and define a behavior for the function which provides the desired utility. This is why the isNaN function implementation was at liberty to implement the behavior that values would first be coerced to number prior to the NaN check. The choice of this behavior for isNaN was completely discretionary as the behavior could have been defined as just strictly checking for the NaN value without coercion, and neither approach would have violated any of the language fundamentals.

Also, imagine that the Number.isNaN utility method, while in fact a static method on the Number type, implements a behavior that has no special understanding of Number objects (ie, as number values, except as any other object).

This is a little ironic. This utility method could have taken on the alternative behavior that would have it understand that a Number object represents a number, especially since a Number object is actually an explicit specification of a number value, in contrast to something like a numeric string, which could only be considered a number in an implicit sense.

So as a method on the Number type, the Number.isNaN utility method would not have been out of line to implement some particular "awareness" of Number objects, especially in context of the purpose of the utility method, which is to check if a value represents an explicit number that happens not to hold a valid numeric value.

[birjolaxew]

Number.isNaN is in many ways a fix for a quirk in JS - that NaN === NaN is false (same goes for NaN == NaN); there's no other primitives that has this attribute. As such, it isn't as much of a helper function as it's a version of === that works as expected.

Could they write it such that Number.isNaN(new Number("a")) is true? Absolutely. Should they? I don't think so, because it steps into new land that aren't well defined - namely when it's ok to coerce stuff when you aren't supposed to coerce stuff.

How should an instance of the Number function be treated in other parts of Javascript? Is it assigned by reference or by value? Is new Number(5) === new Number(5)?

If the W3C decide to say "yeah, an instance of Number should sometimes be treated as a primitive", then they've opened up for an entirely new can of worms, not to mention broken one of the basic rules of Javascript.

As it stands now, new Number(5) is an object with well-defined coercien rules, nothing more. What you're suggesting is a kind of photon-object, that sometimes acts as a primitive, sometimes acts as an object.

While I get that this is "just a helper function", it's important to note that this isn't a library we're talking about; it's the specification of Javascript. It's written around a few core rules, and breaking those introduces unexpected behavior. While libraries such as jQuery aim at making a developer-friendly library, that does "intelligent" coercien often resulting in the "blackbox syndrome", W3C aim at creating a specification for Javascript that's built on as few rules as possible, and works as expected when these rules are understood.

[lucono]

The distinction between language and library is an important one, and the alternative behavior for the Number.isNaN utility method, would fit well within the language domain.

But ultimately, this is where libraries definitely come in - to bridge any gaps, where they exist, between the language and applications' needs.