Ability to pass a generic function as a parameter to a generic function - (perhaps the best way to implement "oneof")

[craigphicks]

🔍 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.

[fatcerberus]

Note that x(1, "") is already disallowed by the rules of generic inference; TS generally doesn't infer unions across candidates.

declare const y: <T>(a: T, b: T) => T;
y(1, "");  // this is an error today

Of course, T can still be a union if one of the candidates is a union, or if specified explicitly. What a proper oneof would do is to prevent T from ever being a union at all.

However, GenFunc is not passed [as] a parameter to OneOf_GenFunc

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]

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 be

1. Possibly indicating that the type definition is a meta-type definition
2. Possibly Indicating that a specific parameter is a generic function
3. Supplying default values to a generic function, which wouldn't need to be a feature in the first version anyway.

For example

type* OneOf<GenFunc><A extends any[], Acc extends Record<number, any>={}> = ...

type* rather than metatype or some other alphabetic identifier because metatype is not reserved.

Then, when

type Adder = OneOf<GenFunc><[number,string]>

is defined, the evaluation is going to be very close to OneOf_GenFunc<[number,string]> from above,
with the exception that GenFunc is "imported" into the context.

I suppose all differences from 1213 could be classified as implementation details, and therefore this really is a duplicate.

[craigphicks]

All right, I'll close this and post a comment at the end of #1213 instead.