Number.isNaN

John-David Dalton john.david.dalton at gmail.com
Thu Dec 13 20:25:06 PST 2012


Yap yap, so thoughts on `BuiltinNumberWrapper` instead of `Type(…)`? It
would still prevent the global `isNaN('foo')` confusion. Though
`Object.is(NaN, Object(NaN))` currently returns `false` too. Was this just
an oversight? I know `Object(NaN)` is totally edge case but it still has
the brand of BultinNumberWrapper and is NaN (boxed).


On Thu, Dec 13, 2012 at 8:18 PM, Luke Hoban <lukeh at microsoft.com> wrote:

> >> From: Mark S. Miller [mailto:erights at google.com]
> >>
> >> In that case, the current spec is wrong. The purpose of introducing
> Number.isNaN is to repair the >> following bug in the global isNaN:
> >>
> >>     isNaN("foo") // returns true
>
> Indeed, as Yusuke noted on the other reply, I referred to the wrong
> 'isNaN'.  And as you note, the point of the 'Number.isNaN' variant is to
> avoid any coercions.
>
> That still leave's JDD's original suggestion to allow
> Number.isNaN(Object(NaN)) to return 'true' by checking for either primitive
> or boxed Number.  It feels a little odd to introduce another kind of
> limited coercion into the language, but perhaps it is practically valuable
> to not differentiate boxed and unboxed numbers here?
>
> Luke
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121213/606e264d/attachment.html>


More information about the es-discuss mailing list