lukeh at microsoft.com
Thu Dec 13 20:18:25 PST 2012
>> 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?
More information about the es-discuss