`isNaN` and `isFinite` should accept number or string

[darrylring]

According to the ES5.1 spec (15.1.2.4, 15.1.2.5), isNaN(number) and isFinite(number) perform the ToNumber(number) abstract operation before checking if number 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?

[RyanCavanaugh]

perform the ToNumber(number) abstract operation

The same is true of many other functions -- Math.max, for example, but we don't allow Math.max(window, 'world').

What's some example code where you'd intentionally pass a non-number to those functions?

[darrylring]

At the very least it should allow a string. "4" is finite. My use case is having a variable of type string | number representing a position -- similar to CSS's vertical-align, it could be "left", "right", "center", or 50, or -10.

if (position == 'right' || (isFinite(position) && position < 0)) {

If isFinite(position) == true, then position is numeric enough to compare to 0. It doesn't matter if position is -4 or "-4", it's finite, and it's less than 0. If it's "left", it's not finite.

Edit: I would make the same argument for Math.max, et al. Math.max("4", 3) gives you the number 4.

[kitsonk]

That sort of unintended coercion I see as one of the major use cases for TypeScript, as there is just too much "flexibility" in ES. I personally would much prefer to throw an error and then for me to explicitly coerce it. It make my code more explicit. While technically it isn't needed at runtime, that is almost the whole point of TypeScript, isn't it?

[RyanCavanaugh]

Implicit coercions are the bane of JavaScript. 99% of the 'wat' things people make fun of JS for are implicit coercions.

Thinking about Math.max and what its signature should be:

• Math.max("4", 3) is 4, which is not === to any of its inputs
• Math.max(" \r\n\t ", -1) is 0, which again is not either of its inputs
• Math.max(10, [11]) is 11. So we should allow number[] as an input to max because it produced a possibly-meaningful result once?
• Math.max(10, [11, 12]) is NaN. So... maybe not number[] ? Or we should assume you know it's only safe to pass single-element arrays to it?

Just because a function produces a result doesn't mean that result is a meaningful one. These are the kind of patterns we'd prefer to error on. isFinite("") === true and "" >= 0, but it's really not clear that anyone wants to treat "" as if it were actually a number.

There's a single-character fix: isFinite(+position). This makes it clear that you want to coerce position to a number.

[darrylring]

I agree with both of you, but I would suggest it's a matter of degree. Let's ignore Math.max() because, as you say, the output can be !== to any of its inputs. I was not originally thinking about it, so my comment was just off-hand.

isFinite("hello") == false is neither unexpected nor unintended. The result makes sense and is meaningful. I understand the + coercion, but I do not agree that it is more clear about anything. Nothing plus a string is a number?

[darrylring]

+"2" // => 2
1+"2" // => "12"

Tell me how this is more explicit or clear. JavaScript is the worst.

[kitsonk]

Well, that is why I don't like the simplified coercions... I prefer to use the more explicit:

Number("2"); // => 2
1 + Number("2"); // => 3

Because of exactly that... No one is going to get confused (including the runtime) about what I am trying to do, including myself. More typing, sure... but far less surprising.

[darrylring]

My thinking is that in the case of isFinite and isNaN, they tell you if something can be coerced into a number that is finite or not. If you're going to use it as a number, it's going to have to be coerced anyways:

if (isFinite(y)) { x += Number(y); }
if (isFinite(Number(y))) { x += Number(y); }

I guess I just don't really see what the second line buys you over the first, at least as far as y being a number or a string goes.

[RyanCavanaugh]

I do not agree that it is more clear about anything. Nothing plus a string is a number?

Unary + is in nearly every programming language -- it might be unclear if you've never seen it before, but the same is true of every operator.

The real problem here is that calling isFinite is a meaningful and well-defined operation on numbers, and an incredibly tricky operation on non-numbers with many counter-intuitive results. Doing the tricky operation by default is dangerous. If you want to perform a coercion, do it explicitly with unary +.

[darrylring]

I realized I should be using a type guard instead. There's no need to coerce anything because I always know what the type is.