Skip to content

Contextual type inference breaks on function parameters with explicit return #53954

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
evankim390 opened this issue Apr 21, 2023 ยท 5 comments
Closed
Labels
Duplicate An existing issue was already created

Comments

@evankim390
Copy link

Bug Report

๐Ÿ”Ž Search Terms

contextual type inference function return generic

๐Ÿ•— Version & Regression Information

  • This is the behavior in every version I tried, and I reviewed the FAQ for entries about generics.

โฏ Playground Link

Playground link with relevant code

๐Ÿ’ป Code

interface Options<K> {
    key: K;
    fn(key: K): any;
}

function id<K>(options: () => Options<K>) {
    throw 'unimplemented';
}

const breaks = id(() => {
    return {
        key: { id: 32 },
        fn(key) {
            // 'key' is of type 'unknown'.(18046)
            return key.id.toString();
        },
    };
});

const works = id(() => ({
    key: { id: 32 },
    fn(key) {
        return key.id.toString();
    },
}));

๐Ÿ™ Actual behavior

The fn parameter type is only correctly inferred in the case where an arrow function is directly returning an object.

๐Ÿ™‚ Expected behavior

I would expect for both cases to be handled consistently.

@RyanCavanaugh
Copy link
Member

Duplicate #47599

@jcalz
Copy link
Contributor

jcalz commented Apr 21, 2023

@RyanCavanaugh Is a block body context sensitive in a way that a concise body isnโ€™t? I suspect as much but Iโ€™d love to hear official word since #47599 doesnโ€™t seem to talk about that specifically.

@ahejlsberg
Copy link
Member

This isn't related to #47599. Rather, it's an issue that was already fixed in #50903. The example works as expected in 5.1.

@ahejlsberg
Copy link
Member

So, I'll call this a duplicate of #50687.

@ahejlsberg ahejlsberg added the Duplicate An existing issue was already created label Apr 22, 2023
@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

5 participants