Built-in functions (e.g. isFinite) type guard and accepting null | undefined (strictNullChecks)

[Deathspike]

TypeScript Version: 2.0.0

Code

// --strictNullChecks
interface IExample {
  value?: number;
}

let example: IExample = {};
if (isFinite(example.value)) { // Accept possibly `undefined`
  let a = example.value; // Narrow to `number`
}

Expected behavior:

• isFinite should accept number | null | undefined rather than strictly number.
• isFinite should act as a type guard.

Actual behavior:
Won't compile because isFinite is not accepting undefined and is not a type guard.

Proposal:

Change:

declare function isFinite(number: number): boolean;

To:

declare function isFinite(number: number | null | undefined): number is number;

I'm pretty sure there are other functions that could use the same love.
I don't mind putting in some hours if this is an accepted direction to take. Let me know :)

[RyanCavanaugh]

Be sure to read contributing.md for instructions on how to make lib.d.ts changes

[jeffreymorlan]

isFinite(null) actually returns true (null gets coerced to 0)

[RyanCavanaugh]

isFinite(null) actually returns true (null gets coerced to 0)

JavaScript (╯°□°)╯︵ ┻━┻

It's probably best to not allow null, then?

[danthegoodman]

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/isFinite

isFinite('0') also returns true. Number.isFinite('0') returns false, but is only available in ES6 land.

Since these functions can take any type for input, I'd like to see the parameter type changed to any.

[RyanCavanaugh]

What are people passing a string to isFinite attempting to determine about that string?

[danthegoodman]

For isFinite, I suppose the developer is trying to determine if the input can be coerced into a finite number.

For Number.isFinite, I am reading in an any and doing a runtime check to ensure the value is a finite number, so not NaN, Infinity, '0' or null.

[mhegazy]

any is the accurate representation of the spec. but we opted into making strict to catch cases more error cases, that otherwise would be masked by coercion, e.g. isFinite(getNumber) instead if isFinite(getNumber()). I suppose changing the type to number|string|null|undefined would be safer.