Repository: TypeScript
Issue: Provide an option to enable stricter type checking of Number.isNaN, Number.isFinite, etc. to catch very obvious bugs
Labels: Suggestion,Awaiting More Feedback

### 🔍 Search Terms

Number.isNan, Number.isFinite

### ✅ Viability Checklist

- [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
- [X] This wouldn't change the runtime behavior of existing JavaScript code
- [X] This could be implemented without emitting different JS based on the types of the expressions
- [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- [X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

https://github.com/microsoft/TypeScript/pull/24436 changed the type signature of Number.isNaN, etc from accepting `number` to `any`.

To be honest, I don't think it was a good idea, because it basically removed type safety from these functions, in exchange for enabling a rare use case that already had easy workarounds if you really needed to do it.

But since reverting that PR now would be a breaking change, it's probably best not to just straight up revert it. Instead, it would be good to have a compiler option to restrict the type signature of these Number.is* functions to only accept `number`, and not other types.

In the projects I've worked on, calling Number.isNaN on any non-number typed variable is almost certainly a bug. I'm not aware of a way that currently exists to automatically detect such a bug. (See also https://stackoverflow.com/questions/76475102/disallow-calling-number-isnan-on-non-numbers-using-e-g-an-eslint-rule )

If there was a compiler option to give these Number.is* functions more restrictive type signatures, I would enable it in all my projects. I have encountered multiple bugs in my projects that would have been prevented by this stricter type checking.

@RyanCavanaugh even [noted in the PR that originally changed this functionality](https://github.com/microsoft/TypeScript/pull/24436#issuecomment-392997204):

> I'm not a huge fan that you can write e.g. Number.isFinite("oops") as it will always be false - this call would be extremely suspect and we should flag it as such." 

### 📃 Motivating Example

In many codebases, there is no reason to ever call `Number.isNan` on a variable that is not a `number` type, and any time this happens, it's a bug.

```
const possibleNumberFromUserInput = "abcd";
// The below evaluates as false - likely a bug in most codebases!
const userInputWasNan = Number.isNaN(possibleNumberFromUserInput);
// Probably the author of this code meant to write the following:
// const const userInputWasNan = Number.isNaN(Number(possibleNumberFromUserInput));
```

### 💻 Use Cases

1. **What do you want to use this for?** Stricter type checking to prevent bugs.
2. **What shortcomings exist with current approaches?** The current approach allows code to compile when its type signatures indicate that it is highly likely to be a bug.
3. **What workarounds are you using in the meantime?** I haven't found any suitable workarounds.