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

Infer generic type from ReturnType #28655

Closed
rdeneau opened this issue Nov 23, 2018 · 2 comments
Closed

Infer generic type from ReturnType #28655

rdeneau opened this issue Nov 23, 2018 · 2 comments
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed

Comments

@rdeneau
Copy link

rdeneau commented Nov 23, 2018

I thought I could answer this stackoverflow question with a generic factory function but it fails:

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

type ItemV1a = ReturnType<typeof createItem>;  // KO: { value: {}; }
type ItemV1b<T> = ReturnType<typeof createItem>;  // KO: <T> ignored. Still { value: {}; }. Expected: { value: T; }
type ItemV1c<T> = ReturnType<typeof createItem<T>>;  // Compile error

const createItemLamdba = <T>(value: T) => ({ value });

type ItemV2a = ReturnType<typeof createItemLamdba>;  // KO: { value: {}; }
type ItemV2b<T> = ReturnType<typeof createItemLamdba>;  // KO: <T> ignored. Still { value: {}; }
type ItemV2c<T> = ReturnType<typeof createItemLamdba<T>>;  // Compile error

Note : I don't see a way to use the infer keyword.

Expected behavior:

Having a generic type returned by ReturnType type, with a special syntax if necessary.

Playground Link:

https://www.typescriptlang.org/play/index.html#src=function%20createItem%3CT%3E(value%3A%20T)%20%7B%0D%0A%20%20%20%20return%20%7B%20value%20%7D%3B%0D%0A%7D%0D%0A%0D%0Atype%20ItemV1a%20%3D%20ReturnType%3Ctypeof%20createItem%3E%3B%20%20%2F%2F%20KO%3A%20%7B%20value%3A%20%7B%7D%3B%20%7D%0D%0Atype%20ItemV1b%3CT%3E%20%3D%20ReturnType%3Ctypeof%20createItem%3E%3B%20%20%2F%2F%20KO%3A%20%3CT%3E%20ignored.%20Still%20%7B%20value%3A%20%7B%7D%3B%20%7D%0D%0Atype%20ItemV1c%3CT%3E%20%3D%20ReturnType%3Ctypeof%20createItem%3CT%3E%3E%3B%20%20%2F%2F%20Compile%20error%0D%0A%0D%0Aconst%20createItemLamdba%20%3D%20%3CT%3E(value%3A%20T)%20%3D%3E%20(%7B%20value%20%7D)%3B%0D%0A%0D%0Atype%20ItemV2a%20%3D%20ReturnType%3Ctypeof%20createItemLamdba%3E%3B%20%20%2F%2F%20KO%3A%20%7B%20value%3A%20%7B%7D%3B%20%7D%0D%0Atype%20ItemV2b%3CT%3E%20%3D%20ReturnType%3Ctypeof%20createItemLamdba%3E%3B%20%20%2F%2F%20KO%3A%20%3CT%3E%20ignored.%20Still%20%7B%20value%3A%20%7B%7D%3B%20%7D%0D%0Atype%20ItemV2c%3CT%3E%20%3D%20ReturnType%3Ctypeof%20createItemLamdba%3CT%3E%3E%3B%20%20%2F%2F%20Compile%20error%0D%0A

@jack-williams
Copy link
Collaborator

I think this is related to this issue: #22617

In particular I would read this comment by Anders that explains the design limitation.

@AnyhowStep
Copy link
Contributor

AnyhowStep commented Nov 23, 2018

My workaround for such cases is, (I'm on my phone so I may make typos)

type CreateValueResult<T> = (
    { value : T }
);
function createValue<T> (value : T) : CreateValueResult<T> {
    return { value };
}

So, when I need to use the return type of the generic function, I just use CreateValueResult<T>

No need to introduce new syntax. No need for a new feature. You do lose the return type inference, though.


In my projects, I have many generic functions that compose each other and TS' inference isn't always accurate. So, I have the type declarations to explicitly type them.

@weswigham weswigham added the Needs Investigation This issue needs a team member to investigate its status. label Nov 26, 2018
@RyanCavanaugh RyanCavanaugh added Design Limitation Constraints of the existing architecture prevent this from being fixed and removed Needs Investigation This issue needs a team member to investigate its status. labels Aug 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed
Projects
None yet
Development

No branches or pull requests

5 participants