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?