parseInt and parseFloat should accept any and not just strings

[MoritzKn]

TypeScript Version: 3.8.3 (playground)

Search Terms:

• "parseInt any"
• "parseInit type"
• "parseInit string"
• "parseFloat any"
• "parseFloat type"
• "parseFloat string"

Code

const maybeNumber: number | string = 1;

// The issue: parseInt only accepts strings so this fails,
// even though the runtime happily accepts any value...
const asNumber1 = parseInt(maybeNumber, 10)

// So the solution would be:
// Convert the number toString() and the string toString() so we can be sure that we never 
// pass numbers into the parseInt function...
const asNumber2 = parseInt(maybeNumber.toString(), 10)

// Or, better do a type check. But we are still duplicating a type check that already exits in the runtime... :/
const asNumber3 = typeof maybeNumber === 'string' ? parseInt(maybeNumber, 10) : maybeNumber

// Or simply accept defeat and out out
const asNumber4 = parseInt(maybeNumber as string, 10)

Expected behavior:

parseInt and parseFloat accepts any.

The spec gives the function the signature parseInt ( string, radix ) but also states that the argument will be converted to string internally (Let inputString be ? ToString(string).).

In my opinion, the type system should allow relaying on the behavior:

1. It improves usability
2. Adding runtime checks creates bigger bundles and slower code (even if only by a tiny margin)

IMHO duplicate type checks should not be encouraged.

Actual behavior:

The first parseInt call returns the type error:

Argument of type 'string | number' is not assignable to parameter of type 'string'.
  Type 'number' is not assignable to type 'string'.(2345)

Playground Link: here

[MartinJohns]

Duplicate of #17203. Search terms: parseFloat.

[MoritzKn]

Sorry, I missed that one. If the desition was made that this behavior is intended, I accept it and don't want to repeat the argument. But if you are willing to revisit this, IMHO it would be an improvement.

I already made my argument above but I have one small addition:
In my experience types like string | number (or any but it's probably a number) are common when taking input from outside TS where you are not 100% sure what the types are. In these cases adding a runtime conversion seems more appropriate to me than a type assertion (as number) and a type check using typeof seems overly verbose.

[RyanCavanaugh]

parseInt(3e20) is 3e20 but parseInt(3e21) is 3. This is not a process you should put arbitrary data through. If you really want to, add a type assertion, because this is a very dangerous process.

[MoritzKn]

Fair point. Though I'd like to point out that parseFloat(Number.MAX_VALUE) === Number.MAX_VALUE works and parseInt(Number.MAX_SAFE_INTEGER) === Number.MAX_SAFE_INTEGER also works. It's just that when you get out of the integer range that you start getting unexpected behavior.

But perhaps is going to be enough for me to actually start writing typeof foo === 'number' ? foo : parseInt(foo, 10).

[typescript-bot]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.