>> From: Mark S. Miller [mailto:[email protected]] >> >> 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
