Provide an option to enable stricter type checking of Number.isNaN, Number.isFinite, etc. to catch very obvious bugs

🔍 Search Terms

Number.isNan, Number.isFinite

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• 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:

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.

Inizia esaminando la modifica delle signature di Number.isNaN e Number.isFinite in TypeScript PR 24436 e gli esempi motivanti in questa issue. Determina come un'opzione del compilatore potrebbe fornire controlli più rigorosi senza compromettere il codice esistente o modificare il JavaScript emesso; il lavoro è completo quando l'opzione e il suo comportamento sono specificati e validati per le funzioni Number.is* elencate.