Skip to content

Autocomplete for overloaded function only suggests first matching signature when discriminant isn't the first field typedΒ #61958

Open
@ajotaos

Description

@ajotaos

πŸ”Ž Search Terms

autocomplete discriminated union overloads

πŸ•— Version & Regression Information

N/A

⏯ Playground Link

https://www.typescriptlang.org/play/?target=9&jsx=0#code/C4TwDgpgBAMglgNwgSQHZgK7CgXigbygGcBjAe0gC4oByAG0QhoG4oAnCOiAQyIgHUIEANbUiwNnFQBzKAF9mAKFCQoAQTp00mbHkKkKEajW6aW7Tjz6CRYiVNkLFigGYZUJYHDKoo0iMDIREQYEEQAFFI61PBI2lgAlMaxTEpuHl4+fgFBIWGR6FjUGlqFwEm0JSyu7p7evv6BwaERUUWwjPHYAD7qml0V4pIyBIpQFsAYbL5twAB0Bqo4y7QMSDRQAPy0KRvGVUpyQA

πŸ’» Code

type LiveInput = { scope: 'live'; releaseWeek: string };
type AllInput = { scope: 'all'; releaseWeek: string };

function getIssues(input: LiveInput): 'Live';
function getIssues(input: AllInput): 'All';
function getIssues(input: LiveInput | AllInput): string {
  return input.scope === 'live' ? 'Live' : 'All';
}

getIssues({ scope: '' })

getIssues({ releaseWeek: '', scope: '' })

πŸ™ Actual behavior

getIssues({
releaseWeek: '',
scope: '', // ← Only one overload shows up here (the first one, live in this case)
});

πŸ™‚ Expected behavior

getIssues({
scope: '', // ← Both overloads show up here
});

Additional information about the issue

Hey TS team πŸ‘‹

I noticed some inconsistent behavior in autocomplete when using function overloads with object literals that rely on a discriminant field like scope. When you're calling a function with multiple overloads, the order in which you type object fields affects which overloads are shown in IntelliSense β€” specifically:

If any other fields in the object literal are already written before the discriminant, then autocomplete will only show the first matching overload, even though others should apply too.

This can make it seem like only one overload exists when in reality multiple are valid.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Domain: Completion ListsThe issue relates to showing completion lists in an editorHelp WantedYou can do thisPossible ImprovementThe current behavior isn't wrong, but it's possible to see that it might be better in some cases

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions