Enum value lookup by string variable should be typed as the enum type.

[marcind]

I'm trying to map a value in a JSON blob that is serialized as a string to application logic code in TypeScript where the value is logically one of a set of values (and then map that back to JSON as a string to send back to a server). Naturally this maps quite well to enums. However, the type of enum value lookups via string variables is inferred as any whereas I would expect it to be the type of the enum. Here's an example:

enum Letter {
    A,
    B
}

var apiModel: { letter: string } = JSON.parse("{'letter':'A'}");
var deserialized = Letter[apiModel.letter]; // Expect inferred type as Letter, but inferred as any
var notALetter: boolean = deserialized; // This should not compile, but it does

I propose that a change be made so that member access of an enum 'type' via a variable typed as string should be an expression with a value that is that enum 'type'.

Some more examples of what I would expect

enum Letter {
    A,
    B
}

var n = 1;
var s = "A";

var fromN = Letter[n]; // Inferred string - as expected
var fromConst = Letter["A"] // Inferred Letter - as expected
var fromS = Letter[s]; // Inferred any - would expect Letter

var numberFromN: number = Letter[n]; // Fails to compile as expected
var numberFromS: number = Letter[s]; // Compiles fine as expected

var letterFromN: Letter = Letter[n]; // Fails to compile as expected
var letterFromS: Letter = Letter[s]; // Compiles fine as expected

var boolFromN: boolean = Letter[n]; // Fails to compile as expected
var boolFromS: boolean = Letter[s]; // Compiles fine - would expect failure

var stringFromN: string = Letter[n]; // Compiles fine as expected
var stringFromS: string = Letter[s]; // Compiles fine - would expect failure

[RyanCavanaugh]

We don't do this on purpose because of this:

var s = "1";
var fromS = Letter[s]; // Runtime value is string, not Letter

If you really actually know that the value you're indexing with is a string key in the enum, use a type assertion.

[danquirk]

Additionally, the way we would enforce this kind of constraint in the type system would be by giving enum's an implicit string indexer that returns the enum type. But this would make it very difficult to add additional members to the enum via a merged module.

[masaeedu]

@RyanCavanaugh Now that we have string literal types and union types, couldn't this be improved somewhat?

[RyanCavanaugh]

@masaeedu which parts specifically?

[masaeedu]

Just spitballing here, but maybe you could automatically generate a union string literal type composed of all the entries in the enum. Any string assignable to that type produces a number, any other string produces any.

[RyanCavanaugh]

You're aware that Letter['A'] is already of type number, right?

[RyanCavanaugh]

Or you're talking about the case where you have var x: 'A' | 'B' and you're indexing by that?

[masaeedu]

@RyanCavanaugh Yeah, that one. That lets users dynamically pick the string, but still get the correct type.

[masaeedu]

Low priority, I know, but if you think it has a shot I could open an issue and attempt a PR.

[RyanCavanaugh]

I think we're already tracking this (essentially) at #6080.

Instead of special-casing enums, we can just say that indexing x by "A"|"B" produces the type of x["A"]|x["B"], which each subcomponent gets the special behavior that you get the actual property type if the properties x.A / x.B exist