🔍 Search Terms

type instantiation
type level generic function
generic return type

Related: #40542, #61133 and maybe #52035?

Edit: Just found #55435 and #40179

✅ 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

#47607 added support for instantiation expressions, but those do not apply at the type level. I understand it'd be ambiguous in some cases (#47607 (comment)), but in some cases there really isn't a reasonable workaround.

📃 Motivating Example

I actually have a very similar case to the example provided in #40542

const provideBox = () => { const box = <T>(value: T) => ({value}); return box; }; type BoxMaker = ReturnType<typeof provideBox> // type BoxMaker = <T>(value: T) => { value: T; } type Box1<T> = ReturnType<BoxMaker<T>>; // Type 'BoxMaker' is not generic.(2315) const box = undefined as unknown as BoxMaker; type Box2<T> = ReturnType<typeof box<T>>; //type Box2<T> = { value: T; } 

{ "compilerOptions": { "strict": true, "noImplicitAny": true, "strictNullChecks": true, "strictFunctionTypes": true, "strictPropertyInitialization": true, "strictBindCallApply": true, "noImplicitThis": true, "noImplicitReturns": true, "alwaysStrict": true, "esModuleInterop": true, "declaration": true, "target": "ES2017", "module": "ESNext", "moduleResolution": "node" } }

Playground Link: Provided

💻 Use Cases

1. What do you want to use this for?

In our case we have a more complex provideBox that accept arguments. We also need to rely on type inference for the generic type of the box function and its return value;

3. What shortcomings exist with current approaches?

I cannot extract and export a generic type for a return value of a generic function if I don't have direct reference to the function.

5. What workarounds are you using in the meantime?

The only workaround I found is to use a dummy runtime value to apply the type, and use and instantiation expression on that dummy value (see Box2 above)