Skip to content

No autocomplete when using something other than any on keyof extends generic #35682

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
Ranguna opened this issue Dec 14, 2019 · 7 comments
Closed
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed

Comments

@Ranguna
Copy link

Ranguna commented Dec 14, 2019

TypeScript Version: 3.7.2 (and latest nightly)

Search Terms:
autocomplete on keyof without any
no autocomplete when extending keyof generic without any

Code

interface C {
    [key: string]: string
}

function fun<T extends C[]>(o: T): { [key in keyof T[number]]: number }{
    o[0][""].
}

let result = fun([{
    v1: "1"
}, {
    v2: "2"
}]);

result. // no `v1` or `v2` autocomplete

Expected behavior:
result should have autocomplete with the following members: v1 and v2.

Actual behavior:
result doesn't have any autocomplete. If interface C is replaced with:

interface C {
    [key: string]: any
}

Everything works as expected but the type of o[number][string] is lost to any inside fun.

Playground Link: https://www.typescriptlang.org/play/index.html#code/JYOwLgpgTgZghgYwgAgMLIN4FgBQz-IDaA1hAJ4BcyAzmFKAOYC6Vt9IDuAvrrjAK4gEYYAHsQyASAA8AFWQQAHpBAATamkJMAfAApRVWQEoqGIqTLJQyC6JjJZhEPwC2AI2hMWyZ++jIubDwCUUIABiZCACIopgA6bl4cABsIMGQoCGp+ZPSAXklBXUIggmQANwBGKijKqO4AGkxcMvKAJhq2+pwuJiMAbiTM7NyEnCA

Related Issued: Maybe #27928

@Ranguna Ranguna changed the title No autocomplete when using something other than any on keyof extended generic No autocomplete when using something other than any on keyof extends generic Dec 14, 2019
@RyanCavanaugh RyanCavanaugh added the Design Limitation Constraints of the existing architecture prevent this from being fixed label Jan 31, 2020
@RyanCavanaugh
Copy link
Member

There isn't a way to make the "inside" and "outside" of this function both work like you expect

@Ranguna
Copy link
Author

Ranguna commented Mar 3, 2020

Hmmm.. Is there any specific reason why this works with

interface C {
    [key: string]: any
}

And not

interface C {
    [key: string]: string
}

?

@Ranguna
Copy link
Author

Ranguna commented Jun 4, 2021

@RyanCavanaugh any reason for closing this issue ?

I can clone it if you think it's necessary.

@RyanCavanaugh
Copy link
Member

@Ranguna issues are open if we intend to do something (or want others to do something). If we kept every issue open despite not having any idea how to address it, openness would not be a communicative aspect of an issue.

@Ranguna
Copy link
Author

Ranguna commented Jun 11, 2021

@RyanCavanaugh so we just ignore issues that we don't know how to fix?

Does that mean that typescript has other bugs that are intentionally ignored?

That's a little sad. This feels like we are avoiding problems.

Openness is just to let people know that a problem exists, fixing the problem is another thing.

Issue open = there's a problem.
Issue closed = problem is fixed (or wasn't a problem to begin with/was a duplicate/etc).

@RyanCavanaugh
Copy link
Member

@Ranguna that's not the definition we've chosen to use

@Ranguna
Copy link
Author

Ranguna commented Jun 11, 2021

It looks like the definition you've chosen is to ignore the problems you can't/don't want to solve.
Either way, it's not up to me to decide and I can only respect your decision. I just hope your "definition" doesn't backfire in the future.

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

2 participants