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

keyof widening to string #20200

Closed
dpogue opened this issue Nov 21, 2017 · 2 comments
Closed

keyof widening to string #20200

dpogue opened this issue Nov 21, 2017 · 2 comments
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed

Comments

@dpogue
Copy link

dpogue commented Nov 21, 2017

TypeScript Version: Version 2.7.0-dev.20171118

Code

class Foo<DataType> {
    public set<K extends keyof DataType>(prop : K, value : DataType[K]) {
        this.update({[prop]: value}); // Error here
    }
  
    update(data: Partial<DataType>) {
        return Promise.resolve(this);
    }
}

Expected behavior:
Compile with no errors.

Actual behavior:
Argument of type { [x: string]: DataType[K]; } is not assignable to parameter of type Partial<DataType>.

This is very similar (but maybe not identical) to #13948 and #15534

@mhegazy
Copy link
Contributor

mhegazy commented Nov 21, 2017

Please see #16687 (comment) for more details

@mhegazy mhegazy added the Suggestion An idea for TypeScript label Nov 21, 2017
@mhegazy mhegazy added this to the Future milestone Nov 21, 2017
@mhegazy mhegazy added the Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature label Nov 21, 2017
@RyanCavanaugh RyanCavanaugh removed this from the Backlog milestone Jul 29, 2019
@RyanCavanaugh RyanCavanaugh added Design Limitation Constraints of the existing architecture prevent this from being fixed and removed Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript labels Jul 29, 2019
@RyanCavanaugh
Copy link
Member

TypeScript has no other way to represent the type of the value produced by {[prop]: value}. We'd need some proposal for an all-encompassing feature for representing that along with use cases and proposed behavior.

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

4 participants