Object key completions on overloaded generic function incorrectly shows keys for primitive types #53734
Closed as not planned
Description
Bug Report
🔎 Search Terms
Refactored function parameter hints with generics are incorrect
🕗 Version & Regression Information
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about Functions and Generics .
⏯ Playground Link
No generics normal: Playground link with relevant code
There are generics, the object wording prompt is incorrect: Playground link with relevant code
There are generics, swapping the overloaded function position shows normal: Playground link with relevant code
💻 Code
// We can quickly address your report if:
// - The code sample is short. Nearly all TypeScript bugs can be demonstrated in 20-30 lines of code!
// - It doesn't use external libraries. These are often issues with the type definitions rather than TypeScript bugs.
// - The incorrectness of the behavior is readily apparent from reading the sample.
// Reports are slower to investigate if:
// - We have to pare too much extraneous code.
// - We have to clone a large repo and validate that the problem isn't elsewhere.
// - The sample is confusing or doesn't clearly demonstrate what's wrong.
type GetRes<T> = {
data: T
}
function get<T = any>(config: string): GetRes<T>
function get<T = any>(config: { url: string }): GetRes<T>
function get<T = any>(config: string | { url: string }): GetRes<T> {
const url = typeof config === 'string' ? config : config.url
const data = 1111
return { data } as GetRes<T>
}
// The object wording prompt is incorrect
get()🙁 Actual behavior
I also don't know why the position of the string parameter refactoring function affects the type hint of the object parameter refactoring function.
🙂 Expected behavior
Does not affect type hints.
Activity
fatcerberus commentedon Apr 11, 2023
I don't understand - what exactly is it here that you think is a bug? The behavior in all of your examples looks the same to me.
coder-hxl commentedon Apr 11, 2023
Bruce Pascoe (@fatcerberus) You can try passing in an object, and you will find that there is no type hint
[-]Refactored function parameter hints with generics are incorrect[/-][+]Object key completions on overloaded generic function incorrectly shows keys for primitive types[/+]RyanCavanaugh commentedon Apr 11, 2023
Andarist commentedon Jun 25, 2023
The difference between those 2 starts in
getCandidateForOverloadFailure. This specifically choosespickLongestCandidateSignaturewhen some signatures have type parameters because choosingcreateUnionOfSignaturesForOverloadFailurewould be too complex here (according to the comment there). And that essentially means here that the first overload is chosen.Both of those argument types (
string | { name: string; age: number; }) reach the completions-related code in the variant without type parameters but thestringis successfully discarded by thisgetApparentPropertiescall. When type parameters are present we could perhaps discardstringto avoid those very dubious completions but we can't easily provide completions fornameandage- this would likely require some bigger changes or smarter "candidates for overload failure" selection.RyanCavanaugh commentedon Dec 3, 2025
Closing language service bugs related to the 6.0 implementation. For more information, see #62827