Skip to content
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

Generic type, vs. type that is a generic function #30548

Closed
4 of 5 tasks
ethanresnick opened this issue Mar 22, 2019 · 2 comments
Closed
4 of 5 tasks

Generic type, vs. type that is a generic function #30548

ethanresnick opened this issue Mar 22, 2019 · 2 comments
Labels
Duplicate An existing issue was already created

Comments

@ethanresnick
Copy link
Contributor

ethanresnick commented Mar 22, 2019

Search Terms

generic type function type typeof

Question/Suggestion

I imagine this has to have come up before, but I couldn't find an exact duplicate. #28655 seems maybe related.

Basically, imagine two types:

type A<T> = (value: T) => T
type B = <T>(value: T) => T

With A, I can easily do:

type A1 = A<"hi"> // (value: "hi") => "hi", as expected.
type A2 = ReturnType<A1> // "hi", as expected

With B, there seems to be no syntax I can use to bind the type variable:

type B1 = B<"hi"> // error, type B is not generic
type B2 = ReturnType<B1> // impossible, because of error above

This becomes an issue in practice when using typeof:

function it<T>(value: T) {
  return value;
}

type C = typeof it; // Gives B, not A, understandably

Is there a workaround here? If not, I guess I'm suggesting that there be one. The current error more or less makes sense because, in the general case, I see that writing B<...> couldn't (easily) work to bind the inner type variables, as B could be something like:

type B = <T extends string>(it: T) => any | <T extends number, U>(it: T) => any 

But, in the original case, where B is <T extends string>(it: T) => any, maybe there could be some operator that I could use to "lift up" the generic to turn B into A and support this case?

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

See #15877 -> #17574

@ethanresnick
Copy link
Contributor Author

Thanks @RyanCavanaugh. I always really appreciate your quick, helpful responses. I'm gonna close this as a duplicate of #17574 (and also probably #29043 and a number of other related issues).

@RyanCavanaugh RyanCavanaugh added the Duplicate An existing issue was already created label Mar 25, 2019
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

2 participants