allen at wirfs-brock.com
Fri Dec 14 08:39:59 PST 2012
No, the whole point of Number.isNaN is to provide a definitively test for NaN number values which cannot be tested for in the usual way using ===. The definitiveness of the test would be lost if other values such a Number wrapper instance also returned true when passed as the argument for Number.isNaN.
Arguably, the Type test in the draft is redundant, but may be clarifying.
If you wanted to test for NaN-ness of either Number values or Number wrappers then the appropriate thing would be to make isNaN an method of Number.prototype.
On Dec 13, 2012, at 7:19 PM, John-David Dalton wrote:
> I noticed that ES6 `Number.isNaN` checks `Type(number)` of Number, would it make sense to instead check that the [[BuiltinBrand]] is BuiltinNumberWrapper similar to `Array.isArray`'s check. This would also allow `Number.isNaN(Object(NaN))` to return `true`. Thoughts?
> - JDD
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss