Repository navigation
Infer return type of function based on safe guard #40802
Description
Search Terms
return type, typeguard, infer type
Suggestion
Typescript should be able to infer the correct return type of a function based on its input + type guards:
function foo(arg: number[] | number) {
if (Array.isArray(arg)) { // typeguard
return [1] // arg is an array, so return is clear to be an array as well
}
return 0 // arg is a number, return type should be 0
}At the moment the return type is always number[] | 0 so you cant use any array or number specific methods on the result
Use Cases
I am a fan of letting typescript do its job and let it infer as much as possible. In this special case, it either prevents me from writing explicit overloads or from using generics. It is just very convenient
Examples
foo([]).push(5) // no error
foo(5).toFixed(2) // no errorChecklist
My suggestion meets these guidelines:
- This wouldn't be a breaking change in existing TypeScript/JavaScript code
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
- This feature would agree with the rest of TypeScript's Design Goals.
PS: I asked about this on stackoverflow here. The answer was that it might be possible but probably too cost intensive. However, I would like to have a second opinion here
Activity
jcalz commentedon Sep 28, 2020
Duplicate of or related to #17747.
It would definitely be a lot more work for the compiler to synthesize a conditional generic signature or set of overloaded signatures. Even without performance considerations, most of the time you wouldn't want this to happen, since the compiler would most likely produce the most complicated mess that exposes the full details of the implementation to callers.
RyanCavanaugh commentedon Sep 28, 2020
There is a very fine line here between "providing good inference" and "reciting the function implementation as the return type". That the array return value corresponded to the array input may entirely be an implementation detail, or may be part of the public contract of the function, and it's really unclear how you would draw the distinction in a way that was intuitive and predictable. Absent other evidence, our stance is that functions aren't instrinsically trying to expose their exact implementations to their callers, so we don't perform this kind of inference.
typescript-bot commentedon Oct 1, 2020
This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.