Number.isNaN

Brendan Eich brendan at mozilla.com
Fri Dec 14 10:21:10 PST 2012


John-David Dalton wrote:
> > But `myNaN === myNaN` is true if `myNaN = Object(NaN)`.
>
> That's my point. Normally testing for NaN can be done via `myNaN !== 
> myNaN` but `Object(NaN)` throws a wrench in that.
> It would be great if there was 1 function that was able to detect NaN, 
> instead of having libs step up and do it.

Why? Who wraps NaN? Your modernizr true-wrapping Boolean example is both 
a WTFJS moment, easily avoided by using a truthy object as Sam pointed 
out, and nothing to do with NaN.

/be
>
> -JDD
>
>
> On Fri, Dec 14, 2012 at 9:12 AM, Nathan Wall <nathan.wall at live.com 
> <mailto:nathan.wall at live.com>> wrote:
>
>     > Wat? This seems to be a good reason to allow `Object(NaN)` and
>     use the
>     > NumberWrapper brand as it cannot be tested via the normal way of
>     > `myNaN !== myNaN`.
>
>     But `myNaN === myNaN` is true if `myNaN = Object(NaN)`. Testing
>     against the object is different. Nothing breaks.
>
>         var myNaN = Object(NaN);
>         [ 1, 3, myNaN ].indexOf(myNaN); // => 2
>
>     Works as expected. The only problem which occurs is when you're
>     working with primitive NaN, in which case the only existing good
>     ways to test for it are `x !== x` and `typeof x == 'number' &&
>     isNaN(x)`. The purpose of `Number.isNaN` is to provide a way to
>     test this case which is easier to read and understand. Note that
>     if `x = Object(NaN)` both of these tests fail.
>
>     Nathan 
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list