-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revert return type narrowing #61136
Revert return type narrowing #61136
Conversation
@typescript-bot test it |
Hey @gabritto, the results of running the DT tests are ready. Everything looks the same! |
@gabritto Here are the results of running the user tests with tsc comparing Everything looks good! |
@gabritto Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
@gabritto Here are the results of running the top 400 repos with tsc comparing Everything looks good! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😢
Should we keep the tests behind for the future, rather than deleting them?
I'll just revert this PR when I re-introduce narrowing for 5.9, so it will have the deleted tests again. |
As discussed in design meeting on Feb 4th, the current design for return type narrowing doesn't work well with object types, and that aspect needs to be fixed before the feature can be released.
My notes on the problem are here: https://gist.github.com/gabritto/b6ebd5f9fc2bb3cfc305027609e66bca
This PR reverts return type narrowing, but keeps the change where we check each branch of a conditional return expression separately, since that change, although a breaking one, uncovered bugs in vscode and Google.
My plan is to later fix return type narrowing and get the fixed version in TS again for the 5.9. The planned fix is to restrict return type narrowing for cases where we the function/return type distinguishes between primitive types or primitive and object types, e.g. cases where the parameter has type
string | number
orstring | string[]
. These are the cases where regular type narrowing already works well, and avoids the problems mentioned in the notes. Then, on top of that restriction, we'll enable embedding the "narrowable" type parameter in an object type (see https://gist.github.com/gabritto/b6ebd5f9fc2bb3cfc305027609e66bca#alternative-2-embedding).