Repository navigation
Ability to pass a generic function as a parameter to a generic function - (perhaps the best way to implement "oneof") #56746
Description
🔍 Search Terms
- Ability to parametrize generic function type Ability to parametrize generic function type #44521
- Instantiation expressions #47607 instantiation expressions (see wish list comments)
- Feature Request: "extends oneof" generic constraint; allows for narrowing type parameters #27808 oneof
✅ 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
Here is an implementation for "oneof" (c.f. #27808) for an example generic function GenFunc
type GenFunc<T> = (a:T, b:T)=>T;
type OneOf_GenFunc<A extends any[], Acc extends Record<number, any>={}> = A extends [] ? Acc :
A extends [infer H, ... infer Rem] ? OneOf_GenFunc<Rem, Acc & GenFunc<H>> : never ;
type Adder = OneOf_GenFunc<[number,string]>;
// type Adder = GenFunc<number> & GenFunc<string>
declare const x:Adder;
declare const nors: number | string;
x(1,1);
x(1,""); // error today
x(nors,1); // error
// compare to
declare const genFunc: <T>(a:T, b:T)=>T;
genFunc(1,1)
genFunc(1,""); // error today
genFunc(nors,""); // no error```
However, `GenFunc` is not passed a parameter to `OneOf_GenFunc`, instead `GenFunc` must exist in the current scope, and so `OneOf_GenFunc` is not generic with respect to `GenFunc`.
If "oneof" were to be implemented as a user defined function or otherwise, then doing so via enabling generic function arguments to generic functions could kill many birds with one stone.
(*Note: The 27808 post content also talks about return type verification inside the generic function implementation body, but that is really a separate issue, and obviously isn't included here).*
### 📃 Motivating Example
See suggestion.
### 💻 Use Cases
1. What do you want to use this for? A multi purpose tool that would also satisfy #27808.
2. What shortcomings exist with current approaches? No current approach.
3. What workarounds are you using in the meantime? Ad Hoc.
Activity
[-]Ability to pass a generic function to a generic function - (perhaps the best way to implement "oneof")[/-][+]Ability to pass a generic function as a parameter to a generic function - (perhaps the best way to implement "oneof")[/+]fatcerberus commentedon Dec 12, 2023
Note that
x(1, "")is already disallowed by the rules of generic inference; TS generally doesn't infer unions across candidates.Of course,
Tcan still be a union if one of the candidates is a union, or if specified explicitly. What a properoneofwould do is to preventTfrom ever being a union at all.This sounds like you want higher-kinded types, for which there are a number of open issues; #1213 is probably the closest to canonical.
craigphicks commentedon Dec 12, 2023
It could be that 1213 is superset of this proposal, at least in terms of satisfying all the desired results describable as "Allow classes to be parametric in other parametric classes".
Conversely, proposal 1213 doesn't mention usability in conditional generic expressions which is the application described here.
Of course those differing applications should ultimately converge anyway. However, it is possible that beginning development with one target or the other would differ in what functionality became available first - i.e., that getting one working wouldn't guarantee the other worked right away without further development.
As for the way the generic function parameters are specified in 1213 - e.g.,
T<*,*>I think arity can be inferred from usage. More important would beFor example
type*rather thanmetatypeor some other alphabetic identifier becausemetatypeis not reserved.Then, when
is defined, the evaluation is going to be very close to
OneOf_GenFunc<[number,string]>from above,with the exception that
GenFuncis "imported" into the context.I suppose all differences from 1213 could be classified as implementation details, and therefore this really is a duplicate.
craigphicks commentedon Dec 12, 2023
All right, I'll close this and post a comment at the end of #1213 instead.