Skip to content

Stop looking at binding patterns for type argument inference - #45719

Merged
Andrew Branch (andrewbranch) merged 2 commits into
microsoft:mainfrom
andrewbranch:bug/43605
Sep 8, 2021
Merged

Stop looking at binding patterns for type argument inference#45719
Andrew Branch (andrewbranch) merged 2 commits into
microsoft:mainfrom
andrewbranch:bug/43605

Conversation

@andrewbranch

Copy link
Copy Markdown
Member

Binding patterns are already sketchy enough as contextual types where type argument inference is not involved, but I see no good reason to let them play a part in actual generic inference.

Fixes #45663
Fixes #43605

Related: #39081

@andrewbranch

Copy link
Copy Markdown
Member Author

@typescript-bot

Copy link
Copy Markdown
Contributor

Heya Andrew Branch (@andrewbranch), I'm starting to run the extended test suite on this PR at c8f6392. Hold tight - I'll update this comment with the log link once the build has been queued.

@typescript-bot

Copy link
Copy Markdown
Contributor

Heya Andrew Branch (@andrewbranch), I'm starting to run the parallelized Definitely Typed test suite on this PR at c8f6392. Hold tight - I'll update this comment with the log link once the build has been queued.

@typescript-bot

Copy link
Copy Markdown
Contributor

Heya Andrew Branch (@andrewbranch), I'm starting to run the inline community code test suite on this PR at c8f6392. Hold tight - I'll update this comment with the log link once the build has been queued.

@andrewbranch Andrew Branch (andrewbranch) added the Breaking Change Would introduce errors in existing code label Sep 3, 2021
@andrewbranch Andrew Branch (andrewbranch) added the Experiment A fork with an experimental idea which might not make it into master label Sep 3, 2021
>oops1 : any
>[1, 2, 3].reduce((accu, el) => accu.concat(el), []) : number
>oops1 : never
>[1, 2, 3].reduce((accu, el) => accu.concat(el), []) : never[]

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We used to think [1, 2, 3].reduce((accu, el) => accu.concat(el), []) is a number. You probably need the (unfortunate) overload resolution error in the function body to get that far off track in the first place, but there’s really no reason why destructuring [oops1] from the result should have any effect on what we think this type is.

@andrewbranch

Copy link
Copy Markdown
Member Author

@typescript-bot

TypeScript Bot (typescript-bot) commented Sep 7, 2021

Copy link
Copy Markdown
Contributor

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

Update: The results are in!

@typescript-bot

TypeScript Bot (typescript-bot) commented Sep 7, 2021

Copy link
Copy Markdown
Contributor

Heya Andrew Branch (@andrewbranch), I've started to run the extended test suite on this PR at c8f6392. You can monitor the build here.

@typescript-bot

TypeScript Bot (typescript-bot) commented Sep 7, 2021

Copy link
Copy Markdown
Contributor

Heya Andrew Branch (@andrewbranch), I've started to run the parallelized Definitely Typed test suite on this PR at c8f6392. You can monitor the build here.

@typescript-bot

Copy link
Copy Markdown
Contributor

Andrew Branch (@andrewbranch)
Great news! no new errors were found between main..refs/pull/45719/merge

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sounds reasonable to me, although I'd like a second opinion from Wesley Wigham (@weswigham) in case there are any unforeseen consequences.

(Although shipping early in 4.5 is probably enough to turn up those consequences as well.)

@weswigham Wesley Wigham (weswigham) left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I mean - I made the original change to elide them when type parameters had defaults; binding patterns are pretty bad inference sources - probably the worst ones we have.

@microsoft Microsoft (microsoft) locked as resolved and limited conversation to collaborators Oct 21, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Author: Team Breaking Change Would introduce errors in existing code Experiment A fork with an experimental idea which might not make it into master For Milestone Bug PRs that fix a bug with a specific milestone

Projects

None yet

4 participants