Skip to content

Should getters still infer the same type from setters over their return expressions? #43414

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
DanielRosenwasser opened this issue Mar 29, 2021 · 4 comments
Labels
Declined The issue was declined as something which matches the TypeScript vision Suggestion An idea for TypeScript

Comments

@DanielRosenwasser
Copy link
Member

class C {
    #x = Promise.resolve("")

    set myValue(x: Promise<string> | string) {
        this.#x = Promise.resolve(x);
    }
    get myValue() {
        return this.#x;
    }
}

Should the get type of myValue be Promise<string> or just string | Promise<string>? Right now it is the latter; but technically, the former provides a more specific type.

Changing this technically would be a breaking change.

@MartinJohns
Copy link
Contributor

MartinJohns commented Mar 29, 2021

Related: #2521 / #42425.

Personally I would keep it as is, and allow users to opt-in to the new behavior with an explicit type annotation.

@ahejlsberg
Copy link
Member

I agree, I don't think there is a compelling case for us to infer divergent getter and setter types.

@RyanCavanaugh RyanCavanaugh added In Discussion Not yet reached consensus Suggestion An idea for TypeScript labels Mar 29, 2021
@RyanCavanaugh
Copy link
Member

I also would prefer to keep the current behavior

@DanielRosenwasser DanielRosenwasser added Declined The issue was declined as something which matches the TypeScript vision and removed In Discussion Not yet reached consensus labels Mar 30, 2021
@DanielRosenwasser
Copy link
Member Author

Consensus'd

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Declined The issue was declined as something which matches the TypeScript vision Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

4 participants