Closed
Description
Suggestion
π Search Terms
- Proposal: Partial Type Argument InferenceΒ #26242
- Partial Generics
- Generic maps
- Generic objects
- Generic inference
β Viability Checklist
My suggestion meets these guidelines:
- 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 feature would agree with the rest of TypeScript's Design Goals.
β Suggestion
We have all heard or seen this PR: #26242 which outlines the technical merits of allowing inference on some, but not all generics. What I am proposing in addition to that core concept is either
- A new way of partially applying generics via an object-like syntax
- Better support for generic inference in generic objects
π Motivating Example
Here is a tweet thread (with codesandbox examples) detailing some of the motivations for this feature: https://twitter.com/tannerlinsley/status/1363926547489456129
π» Use Cases
- Allowing users to customize only some generics for a type or function without needing to know the number of generics, eg. no
LibraryType<*, *, *, *, *, *, TData> // Oops! LibraryType expected 5 generic arguments, not 7.
- In the tweets and codesandboxes in that tweet, you can see some potential workarounds for allowing this type of behavior, but both are limited in either TS's ability to infer types nested in an object literal, or the ability for Ts to infer all generics after user-supplied ones (Proposal: Partial Type Argument InferenceΒ #26242 would fix this, but would still have the issue of
Type<*,*,*,*,*,TDData>
)
Metadata
Metadata
Assignees
Labels
No labels