What is the reasoning behind isNaN's implementation?

Viewed 126

Although the name of the function isNaN refers semantically to the value isNaN, the native implementation returns true for some non-NaN objects like undefined or {}.

isNaN(undefined);
=> true

I think, e.g., underscore's implementation is much more intuitive/logical:

_.isNaN(undefined);
=> false

Why did the ECMA standard specify such a counterintuitive behavior?

Why didn't they design isNaN to return true only if the value to test is really isNaN and leave the burden to test for convertability-to-number on a separate isNumber function?

Doing it this way would have led to even more advantages like no double negative when testing for numbers:

if (isNumber(x)) { } // if x is a number

instead of

if (!isNaN(x)) { }   // if x is not not a number

Since they are going to introduce Number.isNaN() in ECMAScript 6 (which does exactly what you would expect from it), it looks like there are more people thinking like this.

So, why did they design isNaN the way it is in the first place? Was it just a wrong decision or was there a good reasoning to do so?

0 Answers
Related