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

Make inference of index signatures more precise #29377

Closed
4 of 5 tasks
aloifolia opened this issue Jan 11, 2019 · 3 comments
Closed
4 of 5 tasks

Make inference of index signatures more precise #29377

aloifolia opened this issue Jan 11, 2019 · 3 comments
Labels
Duplicate An existing issue was already created

Comments

@aloifolia
Copy link

Search Terms

index signature, object, value, field

Suggestion

Currently, it is not possible (or I missing some crucial knowledge here) to infer the concrete type of the value of an object field. So while in the following code the compiler correctly infers bar for a

const a = 'bar'
type b = (typeof a); // this yields "foo"

it fails to do the equivalent in the following example

const t = { foo: 'bar' };
type u = (typeof t)['foo']; // this yields string

The compiler should literal types for values in objects, as well.

Use Cases

I would like to be able to infer the types of configuration objects without having to explicitly annotate them. This would allow me to write such objects without much hassle and simultaneously use Typescripts inference mechanism to reason about the well-definedness of these values.

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.
@jack-williams
Copy link
Collaborator

Essentially a duplicate of #10195 I think.

@weswigham weswigham added the Duplicate An existing issue was already created label Jan 11, 2019
@aloifolia
Copy link
Author

@jack-williams Yes, I guess this is a specific case of the more general inference problem mentioned in #10195. I summarized my findings there, as well.

@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

4 participants