Typescript: isNaN parameter should be any (or unknown?)

[victorz]

According to the spec (see references below), isNaN() should be able to take any kind of value, which would be coerced into a number (using something like Number(value), which seems to make sense from my tests).

Forcing the parameter to be number breaks legacy code which relies on being able to pass string arguments to isNaN().

function f(value: string) {
  if (isNaN(value)) { // compilation error, but should be OK
    ...
  }
}

Removing the string type from the value parameter admittedly fixes the compilation error, but breaks the "no implicity any" rule.

References:

• Spec: https://tc39.es/ecma262/#sec-isnan-number
• Type declaration: https://github.com/microsoft/TypeScript/blob/f8083d291719c7671a876578234edea0ee33d624/lib/lib.es5.d.ts#L53

[MartinJohns]

Please respect the issue templates for bug reports and feature requests.

---

Both issue templates urge you to first search for existing issues and asks for information (including the search terms you have used to search for existing issues).

This is a duplicate of:

• #3947
• #4002
• #11414
• #12302
• #13227
• #15173
• #16427
• #19153
• #21065
• #23464
• #29607
• #34609

Search terms used: isNaN

---

Forcing the parameter to be number breaks legacy code which relies on being able to pass string arguments to isNaN().

For this case you have several options:

• Overload the signature of isNaN yourself using declaration merging.
• Use a type assertion on your arguments whenever calling isNaN.
• Provide a custom isNaN function that accepts any argument, then within your custom function call the existing isNaN function (I'd opt for this approach).

[victorz]

Huh. Fair enough. I see your point in alternate solutions.

However, the original reason for closing the first report of this issue is incorrect. https://github.com/microsoft/TypeScript/pull/3947#issuecomment-123558773

Reading more the ecmascript doc the argument is specified as Number.

"Number" in the spec is not the type, confusingly enough. It's the parameter name. That becomes evident when you read the algorithm for isNaN().

Regarding searching for issues and issue templates: I simply found the line of code I was looking for in the GitHub project file browser, clicked the little ellipsis next to the line number, and selected "Reference this in a new issue." There was no issue template. Sorry for that, I suppose. I typed "isNaN" in the title but none of the "similar issues" were the same as this one in my opinion. I don't mean to get defensive but I tried and sometimes mistakes happen.

Either way, I still feel like this is in violation of the spec, and that Number.isNaN() should be the one whose parameter should have type number.

Thank you for your consideration.