Repository navigation
Type instantiation for type level generic function #62524
Description
🔍 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; }
Compiler Options
{
"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
- 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;
- 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.
- 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)
Activity
RyanCavanaugh commentedon Oct 2, 2025
Duplicate #40179
mhofman commentedon Oct 2, 2025
I'm not sure what I described can always be a duplicate of #40179
In particular, there may not be runtime arguments to be provided, yet the result can be a generic (requiring explicit generic type on the function call).
I-Enderlord-I commentedon Nov 23, 2025
This feature would be immensely useful when constructing types from generic types. I have seen the comment about ambiguity in #47607, but I honestly don't see why that would be a problem. At the time of type checking it is known whether a type identifier is generic or not. And when it is, instantiating a generic function inside it should simply not work. Think of
There is simply no way to pass a concrete type into
Ybefore specifyingXas the constraint is not known. So writingshould obviously set
Xtostringand notY, resolving asand then making it possible to do
to get
I-Enderlord-I commentedon Nov 23, 2025
Also issues like #40179 are definitely not duplicates of, but merely included in this, as there the discussion is solely on return types. Having type instantiation would also allow