Skip to content
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 binding pattern inference changes, but only for tuples #46009

Closed

Conversation

andrewbranch
Copy link
Member

Partial revert of #45719—we now let an array binding pattern turn inference of an array into a tuple, which is really nice. I still think the behavior we were seeing for object binding patterns was undesirable, and #45846 supports that hypothesis since all the related errors were due to a tuple turning into an array.

@typescript-bot typescript-bot added Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug labels Sep 22, 2021
@andrewbranch
Copy link
Member Author

@typescript-bot user test this inline

@typescript-bot
Copy link
Collaborator

typescript-bot commented Sep 22, 2021

Heya @andrewbranch, I've started to run the inline community code test suite on this PR at c3bcc4c. You can monitor the build here.

Update: The results are in!

@typescript-bot
Copy link
Collaborator

@andrewbranch
Great news! no new errors were found between main..refs/pull/46009/merge

@andrewbranch
Copy link
Member Author

We realized that

declare function f<T>(): T;
const [a, b, c] = f();

should really error, and this PR makes it legal (T is inferred as [any, any, any]). While it may be true that object binding patterns never contribute anything useful to type argument inference, it is not true that array binding patterns always contribute usefully to type argument inference. What we really want is for binding patterns to contribute contextual typing information to other inference sources, while never being allowed to stand on their own as inference sources. I’m going to close this and do a full revert of #45719 so we can investigate a more thorough solution in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants