Stop looking at binding patterns for type argument inference#45719
Stop looking at binding patterns for type argument inference#45719andrewbranch merged 2 commits intomicrosoft:mainfrom
Conversation
|
@typescript-bot user test this inline |
|
Heya @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. |
|
Heya @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. |
|
Heya @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. |
| >oops1 : any | ||
| >[1, 2, 3].reduce((accu, el) => accu.concat(el), []) : number | ||
| >oops1 : never | ||
| >[1, 2, 3].reduce((accu, el) => accu.concat(el), []) : never[] |
There was a problem hiding this comment.
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.
|
@typescript-bot user test this inline |
|
Heya @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! |
|
Heya @andrewbranch, I've started to run the extended test suite on this PR at c8f6392. You can monitor the build here. |
|
Heya @andrewbranch, I've started to run the parallelized Definitely Typed test suite on this PR at c8f6392. You can monitor the build here. |
|
@andrewbranch |
sandersn
left a comment
There was a problem hiding this comment.
This sounds reasonable to me, although I'd like a second opinion from @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
left a comment
There was a problem hiding this comment.
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.
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