Skip to content

Result of F#foo() is not assignable to ReturnType<F["foo"]> #47900

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
jtbandes opened this issue Feb 15, 2022 · 2 comments
Closed

Result of F#foo() is not assignable to ReturnType<F["foo"]> #47900

jtbandes opened this issue Feb 15, 2022 · 2 comments
Labels
Duplicate An existing issue was already created

Comments

@jtbandes
Copy link
Contributor

Bug Report

🔎 Search Terms

extends interface union ReturnType, not assignable to ReturnType

🕗 Version & Regression Information

  • This is the behavior in every version I tried, and I reviewed the FAQ for entries about the above search terms

⏯ Playground Link

Playground link with relevant code

💻 Code

interface Foo {
  foo(): "bar" | "baz";
}
function run<F extends Foo>(f: F): ReturnType<F['foo']> {
  return f.foo(); // works without ReturnType, doesn't work with it
}
let bar = run({ foo: () => "bar" as const });
let _: "bar" = bar; // works with ReturnType, doesn't work without it

🙁 Actual behavior

I'm unable to write a type annotation for function run() that allows the return type to be refined based on the specific F being passed in (with the requirement F extends Foo). When I add the ReturnType annotation, the function body has an error. When I remove it, the function return type is inferred based on the interface requirement of "bar" | "baz" rather than the more specific return type of F["foo"].

Writing return f.foo() as ReturnType<F['foo']> also works, but the as cast is undesirable.

🙂 Expected behavior

It should be possible to write a type annotation for run such that run({ foo: () => "bar" as const }) is inferred to return "bar".

@RyanCavanaugh RyanCavanaugh added the Duplicate An existing issue was already created label Feb 16, 2022
@RyanCavanaugh
Copy link
Member

See #24277

@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

3 participants