Completions for type arguments of expressions #61751

🔍 Search Terms

generic, function, class, call, apply, construct, "type parameter", "type argument", completion, suggestion, autocomplete, intellisense

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

#43526 implemented completions within type arguments of generic types. It would be nice to extend that behavior to the expression level, suggesting completions within type arguments of generic function calls, new expressions, etc.

📃 Motivating Example

In this code, foo is suggested:

type A<T extends { foo: unknown }> = T
type _ = A<{/* trigger completions here */}>

(Playground)

In this code it's not:

function f<T extends { foo: unknown }>() {}
f<{/* trigger completions here */}>()

(Playground)

Related Issues

• No string completions in type arguments where constrained to string literal union #52898 and No IntelliSense for generic literal types #34771 both focus specifically on completions in string literals within type arguments.
• No completions from tsserver for property values in generic type arguments #56299 is about completions of property values within type arguments, which Completion list for type literals in type arguments #43526 did not implement (it only handled property names).