Number.isNaN

Mark S. Miller erights at google.com
Thu Dec 13 20:36:02 PST 2012


On Thu, Dec 13, 2012 at 8:25 PM, John-David Dalton
<john.david.dalton at gmail.com> wrote:
> 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?

No. Object.is correctly reports that these are different.


> 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
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



--
    Cheers,
    --MarkM


More information about the es-discuss mailing list