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:

  TypeScript/lib/lib.es5.d.ts

  Line 53 in f8083d2

  declare function isNaN(number: number): boolean;

[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:

• isNaN accept all types of arguments #3947
• isNaN and isFinite should accept number or string #4002
• Modified isNaN definition to be able to receive any kind of value. #11414
• Type guard of Number.isNaN is wrong #12302
• isNaN() should accept any value (in type definition) #13227
• isNaN only takes number and does not implement typeguard #15173
• Number check functions such as isNaN shouldn't constrain their parameter type #16427
• Lib definition for isNaN wrong #19153
• isNaN expecting a number argument #21065
• isNan() argument type #23464
• isNaN(number: number) should accept string values #29607
• isNaN is restricted to number as arguments only #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. #3947 (comment)

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.

[victorz]

I don't know where this comment by "Aaron Paterson" went (removed?), but I thought it was very insightful:

I do think that both the issue reporters and issue closers are making misinterpretations of the ECMA spec. Number.isNaN and isNaN are both intended to be used on non-number values and should be typed accordingly, for the same reason that both === and == are valid operators in typescript. An example/counterexample is that isNan("NaN") is true while Number.isNan("NaN") is false, not because isNan is coercing "NaN" incorrectly, but because it is meant to coerce "NaN" as per the spec. I can see the benefit to code clarity of making ts users do toNaN(Number("NaN")) rather than rely on ECMA's ToNumber algorithm, but it would be more appropriate to make your own standard library to address those concerns rather than misrepresent ECMA's.