isNaN accept all types of arguments

[dcharbonnier]

According to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/isNaN the argument can be a boolean, a string, a number or an object.

[msftclas]

Hi @dcharbonnier, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

[DanielRosenwasser]

"or string"

[DanielRosenwasser]

What about booleans, as you originally wrote?

[DanielRosenwasser]

On one hand, I feel like this would fail to catch bugs, and if one really needs, they can always use a type guard (i.e. typeof a === "number" && isNaN(a)). On the other, the function is more general in its inputs, so this is a valid change.

[RyanCavanaugh]

I'm struggling with utility of this. isNaN is just going to coerce the argument to a number, so writing isNaN(+x) is always going to be clearer in intent than isNaN(x) for non-number types of x.

Other function like Math.pow work the same way (e.g. Math.pow("3", " 5 ")) but aren't typed as accepting any type.

[dcharbonnier]

Reading more the ecmascript doc the argument is specified as Number. String is a 'free' implementation of the specs.
Sorry for the noise

[DanielRosenwasser]

No worries - always worth discussing!

[darrylring]

According to the ES5.1 specification, the isNaN and isFinite functions use the ToNumber abstract operation on the argument and return true if that result coerces to NaN or ±Infinity. To me, this implies that the argument to these functions can be any type. I think TypeScript should follow this as well.

Why check if a variable is a number before checking if it's not a number (NaN)? Why manually coerce a variable into a number before calling a function that, according to the specification, does just that?

Edit: I just created issue #4002.