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 <lu...@microsoft.com> wrote: > >> From: Mark S. Miller [mailto:erig...@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 > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
