Uh oh!
There was an error while loading. Please reload this page.
narrow by instanceof: infer type parameters from original type - #30161
Conversation
Just as a heads up, your commits don't seem to be associated with your GitHub account. While this isn't technically a problem, you might care if you want more appropriate attribution. You can either make sure your GitHub account is associated with the email address you're using for your commits, or rebase and amend your commits to fix the author name and email. |
Ryan Cavanaugh (RyanCavanaugh)
commented
Apr 25, 2019
TypeScript Bot (@typescript-bot) test this |
Heya Ryan Cavanaugh (@RyanCavanaugh), I've started to run the extended test suite on this PR at f133aed. You can monitor the build here. It should now contribute to this PR's status checks. |
Ryan Cavanaugh (RyanCavanaugh)
commented
Apr 25, 2019
TypeScript Bot (@typescript-bot) test this new one |
Heya Ryan Cavanaugh (@RyanCavanaugh), I've started to run the extended test suite on this PR at 6443775. You can monitor the build here. It should now contribute to this PR's status checks. |
Ryan Cavanaugh (RyanCavanaugh)
commented
Apr 25, 2019
The bot lies; RWC is clean. TypeScript Bot (@typescript-bot) perf test this |
Heya Ryan Cavanaugh (@RyanCavanaugh), I've started to run the perf test suite on this PR at 6443775. You can monitor the build here. It should now contribute to this PR's status checks. Update: The results are in! |
Ryan Cavanaugh (RyanCavanaugh)
commented
Apr 25, 2019
Anders Hejlsberg (@ahejlsberg) take a look? Interesting change |
TypeScript Bot (typescript-bot)
commented
Apr 26, 2019
Ryan Cavanaugh (@RyanCavanaugh) Here they are:Comparison Report - master..30161
System
Hosts
Scenarios
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bruce Pascoe (fatcerberus)
commented
May 6, 2019
Will this also fix this case: classQuery<T>{}functionf<T>(q: T[]|Query<T>){if(Array.isArray(q)){q;// T[], so far so good}elseif(qinstanceofQuery){q;// Query<any>, wtpf}}In my case there's no inheritance. I'm literally only checking if it's one of the types already named in the union and it goes and widens it from |
Nathan Fenner (Nathan-Fenner)
commented
May 6, 2019
Bruce Pascoe (@fatcerberus) I think that it should handle that case, but I'm not sure whether the custom type guard in |
Bruce Pascoe (fatcerberus)
commented
May 6, 2019
The |
Nathan Fenner (Nathan-Fenner)
commented
May 6, 2019
This does fix the unnecessary widening issue. |
I'm going to update the test to better organize the various facets of this feature that are being tested. Here are a few samples (commented annotations are taken mechanically from the generated functiondontWidenPointlessly(){classQuery<T>{uses: T;}functionf<T>(p: T[]|Query<T>){if(Array.isArray(p)){p;// p: T[]}elseif(qinstanceofQuery){p;// p: Query<T>}}}I've identified some bugs/limitations that need to be corrected before moving forward: functionunion(){classParent<A>{a: A;}classChild<B>extendsParent<B>{b: B;}functionmultipleParents(p: Parent<number>|Parent<string>|Parent<boolean>){if(pinstanceofChild){p;// p: Child<number> | Child<string> | Child<boolean>}else{p;// p: Parent<number> | Parent<string> | Parent<boolean>}}functionmixedChildren(p: Parent<number>|Child<string>){if(pinstanceofChild){p;// p: Child<string>}else{p;// p: Parent<number>}}functionimcompatibleOptions(p: Parent<number>|Parent<string>|{foo: boolean}){if(pinstanceofChild){p;// p: Child<any>}else{p;// p: Parent<number> | Parent<string> | { foo: boolean; }}}}There are several problems visible here:
|
Nathan Fenner (Nathan-Fenner)
commented
May 7, 2019
It occurs to me that the theory behind the current implementation is not terribly sound. At the same time, it's not entirely obvious to me how this can be corrected. When we have letx: T;if(xinstanceofK){
...
}and x: T&(exists<t1extendsC1,t2extendsC2>inK<t1,t2>)That is, we know that it's still a The trick is that in many (but not obviously all) cases we can simplify this to remove the existential, producing a type that can be expressed in TS today, and is functionally the same. For example, On the other hand, consta: {f:1|2}={f: 1};constb: {f:number}=a;b.f=3;The way this could be done soundly is by annotating every field with a consta: {readonlyf : 1|2}&{writeonlyf: 1|2}={f: 1};constb: {readonlyf : number}&{writeonlyf : 1|2}=a;b.f=3;// error, f is only writeonly with 1 | 2
Moving back to the original problem, we would like to say that What this suggests as an alternative, sound(ish) procedure is to therefore consider the type This partly simplifies the view of what must be done- many easy cases fall out immediately. The main problem are object and intersection types (since they have fields, and those fields must be compared against the existential) whereas all other instances are either |
Bruce Pascoe (fatcerberus)
commented
May 8, 2019
consta: {f:1|2}={f: 1};constb: {f:number}=a;b.f=3;This kind of blew my mind. Thinking about it, I guess enforcing the contravariance here might be too restrictive in practice; it would effectively make all objects invariant unless they consisted of nothing but Still thought-provoking, though. |
Unfortunately, we never finished reviewing this PR. It is pretty old now, so I'm going to close it to reduce the number of open PRs. |
TypeScript Bot (typescript-bot)
commented
May 24, 2022
The TypeScript team hasn't accepted the linked issue #28560. If you can get it accepted, this PR will have a better chance of being reviewed. |
This change fixes#28560 by inferring (where possible) the generic type parameters for a class when it's narrowed to by the
instanceofoperator.The general process is to infer the parameters as though performing an assignability check of
new Child(...)to the super type. This means that it handles e.g.and anything else you might try to throw at it.
This is a breaking change. However, nothing in the test suite broke (the only changes would be in the newly-added test case that covers this behavior).
It therefore might be a good idea to put it behind a new strict flag, e.g.
--stricterInstanceofNarrowing. However, depending on whether anyone out in the world breaks, that might not be needed.Not all cases are fully covered (i.e. they still infer
anyfor some/all type parameters), or otherwise behave in a (potentially) unexpected (albeit correct) manner:the resulting type is the most-specific sound(ish) type. It's unlikely anyone deliberately will encounter this case (it should be the case that the
Childtype is uninhabited in that case).