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

Type inference for constant objects with string literal types #32139

Closed
4 of 5 tasks
ghost opened this issue Jun 27, 2019 · 4 comments
Closed
4 of 5 tasks

Type inference for constant objects with string literal types #32139

ghost opened this issue Jun 27, 2019 · 4 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@ghost
Copy link

ghost commented Jun 27, 2019

Hi!

Let's say that I have this code:

interface Greeter {
    hello: 'world'
}

function hello() {
    const first: Greeter = {
        hello: 'world'
    };

    const obj = {
        hello: 'world'
    };

    const second: Greeter = obj;
}

For the first object the compiler can infer type of hello as a string literal type and outputs no errors. However, for the second object can't infer this, although obj is a constant object, and throws an error.

It would be nice to have automatic inference here. For example, in Flow types are inferred here automatically and the same code passes type checks without errors.

Addition: specifying the string type literal explicitly helps:

const obj = {
    hello: 'world' as 'world'
}

but makes the code look verbose.

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.
@MartinJohns
Copy link
Contributor

MartinJohns commented Jun 27, 2019

However, for the second object can't infer this, although obj is a constant object, and throws an error.

The variable obj is constant, but the object is not. You can re-assign a new value with obj.hello = "fubar"; just fine.

What you want can be achieve with the "const contexts" feature introduced in TypeScript 3.4: #29510

const obj = { hello: 'world' } as const;

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code

This would definitely be a breaking change in existing code. If it would infer obj.hello as the type 'world', then re-assigning a different string would not work anymore.

@ghost
Copy link
Author

ghost commented Jun 27, 2019

What you want can be achieve with the "const contexts" feature introduced in TypeScript 3.4: #29510

Yes, "const contexts" make the code look better here, I didn't know about them.

This would definitely be a breaking change in existing code. If it would infer obj.hello as the type 'world', then re-assigning a different string would not work anymore.

I agree, so what I was actually thinking about was more similar to automatic inference of "const context" in some cases. In my example "obj" cannot be changed from the outside of the function and it is not changed inside, so in this particular case the compiler could infer that obj.hello can never change.

@MartinJohns
Copy link
Contributor

I was actually thinking about was more similar to automatic inference of "const context" in some cases.

I see. Personally I think it's really not worth the additional code (complexity) and performance cost (the analysis), when we already have a very good feature to solve this without hassle: const contexts.

@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Jun 27, 2019
@typescript-bot
Copy link
Collaborator

This issue has been marked 'Working as Intended' 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
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

3 participants