Skip to content

Unify generic functions and generic types #40792

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
4 tasks done
warent opened this issue Sep 27, 2020 · 4 comments
Closed
4 tasks done

Unify generic functions and generic types #40792

warent opened this issue Sep 27, 2020 · 4 comments
Labels
Duplicate An existing issue was already created

Comments

@warent
Copy link

warent commented Sep 27, 2020

Search Terms

generic function to generic type
parameters< partial application
partial generic parameters

Suggestion

At the moment there seem to be two distinct kinds of generics: those which refer to types and those which refer to functions. It would be ideal if you could talk about the two interchangeably or get a generic type from a generic function.

Use Cases

This would allow us to reflect and/or copy the typings applied to functions using certain generics. In other words, we could reflect on the changes of a generic function's typings under different constraints in different parts of the code.

For example, it could be useful for factories which can combine multiple functions into a single pipeline.
Shortcomings of current approaches listed with examples below.

Another example, we could copy a function signature into another function with some of the generics partially applied / curried.

Examples

const f = <T extends any>(id: T): T => id;
type F = Parameters<typeof<"hello"> f>[0];

This would make F strictly typed to "hello"
At the moment, this isn't possible. The best we can do is something like:

const f = <T extends any>(id: T): T => id;
type F = Parameters<typeof f>[0];

But this just makes F: any which is not helpful if we're trying to analyze the behavior of a function under certain generics.

Here's a larger, contrived example of how it might work in a larger context.

const fn = <T extends any>({ id, hello } : { id: T, hello: T }): { id: T, hello: T } => ({ id, hello })
const fn2 = <T extends any>({ id, some } : { id: T, some: T }): { id: T, some: T } => ({ id, some })

const fns = [
    fn,
    fn2
];

const Factory = <T extends any>(actions: {
    fn: (typeof<T> fns[number]),
    id: T,
    params: Parameters<typeof<T> fns[number]>[0],
}[], cb: (params: Parameters<typeof<T> fns[number]>[0]): ReturnType<typeof<T> fns[number]> => {
    cb(actions[0].fn({ id: actions[0].id, ...actions[0].params }));
});

Factory([{
    fn: fns[0],
    id: "hello",
    params: {
        hello: "world"
    }
}, {
    fn: fns[1],
    id: 123,
    params: {
        some: 456
    }
},  {
    fn: fns[0],
    id: 123,
    params: {
        hello: "oops" // not allowed
    }
}], ({ id, ...result }) => {
    // We know every value of id
    if (id === "hello") {
        // we now know the contents of result
    }
});

This is just one idea. It's kind of a rough interpretation of something I'm trying to do in a production application (where I combine various generic callbacks of a variety of different React components into a single one, and we identify the types of the parameters passed up the chain by the id parameter passed along with it).

There are of course many other potential uses.

It has been discussed previously on StackOverflow (not my post) https://stackoverflow.com/questions/62720954/typescript-how-to-create-a-generic-type-alias-for-a-generic-function

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
  • [unsure] 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, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.
@MartinJohns
Copy link
Contributor

Looks like a duplicate of #37181 to me.

@RyanCavanaugh RyanCavanaugh added the Duplicate An existing issue was already created label Sep 28, 2020
@RyanCavanaugh
Copy link
Member

I believe the linked issue is an exactish duplicate; you might want to review what's in there and post a comment chiming in with some additional use cases if any are missing. Thanks!

@warent
Copy link
Author

warent commented Sep 28, 2020

Already done, thanks @RyanCavanaugh & @MartinJohns

@typescript-bot
Copy link
Collaborator

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

4 participants