You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In order to ensure that any generic type Foo<T> is at least co-variant with respect to T no matter how Foo uses T, TypeScript relates parameters bi-variantly (given that parameters are input positions, they naturally relate only contra-variantly). However, when source and target parameters both have function types with a single call signature, we know we are relating two callback parameters. In that case it is sufficient to only relate the parameters of the signatures co-variantly because, similar to return values, callback parameters are output positions. With this PR we introduce that change. This means that a Promise<T> or Observable<T>, where T is used only in callback parameter positions, will be co-variant (as opposed to bi-variant) with respect to T, which solves a commonly reported issue.
This change finds several issues in our real world code suites that all appear to be legitimate inconsistencies.
@ShawnTalbert If not clear. This PR does not introduce any new syntax. Instead changes type assignability of generics where the type is only user in a function parameter position e.g Promise / Observable
interfaceBox<T>{foo(cb: (t: T=>void)): void;}
Before:
declareconstbA: Box<Animal>;constbC: Box<Cat>=bA;// no error 😿
It appears that the solution was amended to ignore union with null/undefined. Should that be dependent on --strictNullChecks? At the moment, this does not seem to address #13513.
@bmcbarron#13513 is fixed by this PR in --strictNullChecks mode. Without --strictNullChecks, undefined is assignable to any type and is effectively ignored in union types, but that has always been the case and isn't going to change.
This doesn't fix this problem unfortunately and this is usually the case if the callbacks are stored in different files and imported.
classAnimal{}classCatextendsAnimal{publicmeow(){}}letpromise: Promise<Animal>=null;promise.then((cat: Cat)=>{//Should error here but does notcat.meow();});
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In order to ensure that any generic type
Foo<T>
is at least co-variant with respect toT
no matter howFoo
usesT
, TypeScript relates parameters bi-variantly (given that parameters are input positions, they naturally relate only contra-variantly). However, when source and target parameters both have function types with a single call signature, we know we are relating two callback parameters. In that case it is sufficient to only relate the parameters of the signatures co-variantly because, similar to return values, callback parameters are output positions. With this PR we introduce that change. This means that aPromise<T>
orObservable<T>
, whereT
is used only in callback parameter positions, will be co-variant (as opposed to bi-variant) with respect toT
, which solves a commonly reported issue.This change finds several issues in our real world code suites that all appear to be legitimate inconsistencies.
Fixes #11022.
Fixes #14770.