TypeScript: lib.d.ts contains wrong typings for Number.isFinite()

I’m not sure whether this is the repo to be putting this issue on, please let me know if it isn’t.

TypeScript Version: 2.2.2

Code Compiling with strict null checks:

 Number.isFinite(undefined);

Expected behavior:

No compile error. The argument to isFinite should be any, because the function is used to check the type. According to the spec at https://www.ecma-international.org/ecma-262/6.0/#sec-number.isfinite the type is checked by the function.

Actual behavior:

error TS2345: Argument of type ‘undefined’ is not assignable to parameter of type ‘number’

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 2
Comments: 18 (12 by maintainers)

Most upvoted comments

Yes, I think Number.isFinite() is intended to be used like Array.isArray, i.e. it is a guard for numbers, not a function that coerces its arguments to number prior to operation.

In this context the right signature for Number.isFinite is:

isFinite(arg: any): arg is number;

In my opinion, Number.isInteger and Number.isSafeInteger should not be changed, because TS doesn’t distinguish between integers and numbers yet. When integers start having their own type at a later point, it would be a breaking change if the above mentioned functions were made is number guards now.

PS: the global isFinite is coercing and all arguments from #4002 apply to it. However, Number.isFinite is different.

Number.isFinite('123'); // false
isFinite('123'); // true

gcnew on May 4, 2017

@mhegazy this is NOT a duplicate of #4002. That story is about the isFinite() function and not about Number.isFinite(). The spec for Number.isFinite() is different and the arguments brought forward in #4002 do not apply here. I still think I have a valid proposal.

rogierschouten on May 4, 2017

From my perspective, if Number.isFinite doesn’t become a guard for number, there is no reason to change the type of arg to any.

gcnew on May 4, 2017