Proposal: better type narrowing in overloaded functions through overload set pruning
See original GitHub issueTypeScript Version: 2.7.2
Search Terms: type inference, type narrowing, overloads
Code
function bar(selector: "A", val: number): number;
function bar(selector: "B", val: string): string;
function bar(selector: "A" | "B", val: number | string): number | string
{
if (selector === "A")
{
const the_selector = selector; // "A"
const the_val = val; // number | string but should be just number
return "foo"; // should give error: when selector is "A" should return a number
}
else
{
const the_selector = selector; // "B"
const the_val = val; // number | string but should be just string
return 42; // should give error: when selector is "B" should return a string
}
}
Issue
The snippet above shows a limitation of the current type inference implementation in TypeScript.
As can be clearly seen from the overloaded declarations, when selector === "A"
we have val: number
and we must return a number
, while when selector === "B"
we have val: string
and we must return a string
. But the type-checker, although able to understand that the_selector
can only be "A"
in the if
block and only "B"
in the else
block, still types the_val
as number | string
in both blocks and allows us to return a string
when selector === "A"
and a number
when selector === "B"
.
Possible Solution
In the implementation of an overloaded function, when the type-checker decides to narrow the type of a parameter (as often happens in if-else
blocks), it should also remove the overloads that don’t match the narrowed parameter type from the overload set, and use the pruned overload set to narrow the types of the other parameters.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:29
- Comments:15
Top GitHub Comments
It would be fantastic if we could do something like this:
The implementation would not be considered one of the overload signatures, and thus the arguments can be properly narrowed.
To preserve compatibility with implicit any, if the feature was only available when
noImplicitAny
is enabled it would be completely backwards compatible as it would only kick in when there were no type arguments on an overloaded constructor/method/function (right now this is an error).Absolutely agreed, this kind of thing would go a long way towards making overloaded functions a lot safer to use. But it might also be a breaking change: overloads can be used to assert/claim type relationships that TS cannot see. Enforcing particular rules may break attempts to use them to circumvent and/or augment those rules in the first place. But then, that usage of overloads always seemed dubious to me…
Also, related to #21879, which is requesting a similar thing for conditional types rather than overloads. The same problems raised there may also apply here.