Favor asserted type in type predicate narrowing #50044
Conversation
typescript-bot
added
Author: Team
For Uncommitted Bug
|
@typescript-bot test this |
|
Heya @ahejlsberg, I've started to run the extended test suite on this PR at a9484d3. You can monitor the build here. |
|
Heya @ahejlsberg, I've started to run the abridged perf test suite on this PR at a9484d3. You can monitor the build here. Update: The results are in! |
|
Heya @ahejlsberg, I've started to run the parallelized Definitely Typed test suite on this PR at a9484d3. You can monitor the build here. |
|
Heya @ahejlsberg, I've started to run the diff-based user code test suite on this PR at a9484d3. You can monitor the build here. Update: The results are in! |
|
Heya @ahejlsberg, I've run the RWC suite on this PR - assuming you're on the TS core team, you can view the resulting diff here. |
|
@ahejlsberg |
|
One new error in the RWC test suite. In the if (!React.isValidElement(element)) {
return;
}
const column: any = {
...element.props, // New error here
};where |
|
@ahejlsberg Here they are:Comparison Report - main..50044
System
Hosts
Scenarios
Developer Information: |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The interface LodashStatic {
isFunction(value: any): value is (...args: any[]) => any;
isNative(value: any): value is (...args: any[]) => any;
}In |
|
How would one write a type guard that pulls a function out of a union of types, then? It seems unfortunate to lose that information. Is this solely because |
isFunction(value: any): value is Function;It's shorter, clearer, and does what you want, i.e. keeps the argument type for any function type, otherwise produces type |
| // because that is the asserted type, but t for `instanceof` because generics aren't reflected in | ||
| // prototype object types. | ||
| const directlyRelated = mapType(matching || type, checkDerived ? | ||
| t => isTypeDerivedFrom(t, c) ? t : isTypeDerivedFrom(c, t) ? c : neverType : |
There was a problem hiding this comment.
Why do you need the new isTypeDerivedFrom checks too?
There was a problem hiding this comment.
The isTypeDerivedFrom check isn't new. It's just that I'm calling it directly instead of indirectly through the isRelated local. Once we know checkDerived is true, we also know that isRelated references isTypeDerivedFrom, so might as well call it directly.
With this PR we consistently favor the asserted type in a type predicate narrowing when both the argument type and the asserted type are subtypes of each other. We used to do this for non-union argument types, but not for unions. Fixes the issue reported here.
In an ideal world we'd fix this issue by having the subtype relationship only consider fresh object literal types subtypes of object types with index signatures, but unfortunately this is too much of a breaking change (I tried in #50013, but I will need to abandon that PR).
Adding a bit more context...
This is our inconsistent behavior in 4.7 (adding
undefinedshouldn't cause an error):In #49625 we changed both of the above to error. That's more consistent, but a breaking change with the new error. With this PR we instead consistently favor the asserted type:
Note that one issue with favoring the asserted type is that CFA continues with that type after the conditional block. Though undesired, that's an effect of how CFA works in the face of mutual subtypes. This behavior was already present for singleton types, but now also extends to union types.
Fixes #49988 (at least partially).