Assign string literals to string enum type

[domoritz]

TypeScript Version: 2.4.0

Code

enum Colors {
    Red = "RED",
    Green = "GREEN",
    Blue = "BLUE",
}

const c1: Colors = Colors.Red;
const c2: Colors = "RED";

Expected behavior:

I'd expect both lines with c1 and c2 to work but only the first compiles.

Actual behavior:

[ts] Type '"RED"' is not assignable to type 'Colors'.
const c2: Colors

[Knagis]

The value of the enum should "RED", not "Red", the latter is the name of the value, not the value itself.

[kitsonk]

@Knagis I think the OP is trying to point out that while the above doesn't work, the following does:

enum Colors {
    Red = 1,
    Green = 2,
    Blue = 3,
}

const c1: Colors = Colors.Red;
const c2: Colors = 1;

It is an incongruence in the language.

[Knagis]

@kitsonk I mainly pointed out that OP was using the wrong constant. It still does not let assign even with the correct one though.

However in your example, unfortunately this also compiles: const c3: Colors = 123;

[domoritz]

Thank you @Knagis. You're right that I used the wrong constant and I corrected my original post.

[RyanCavanaugh]

The intent of string enums is that the values of the enum are opaque (i.e. they can be changed behind the scenes without breaking consumers). If you don't want that behavior, it's easy enough to use the pre-string-enum workarounds to create similar union types.

Numeric enums allow assignments from arbitrary numbers because we need to support bitflag enums and the | / & / etc operators return number. There's no corresponding behavior for string enums that needs to be supported.

Why don't | and & return enum types when their operands are enum types? I have no idea.

[domoritz]

Thanks for the explanation @RyanCavanaugh! Can you point me to some documentation for the best practice workarounds from pre-string-enums? I'm currently using namespaces (https://github.com/vega/vega-lite/blob/6ea812df890070f4cc7f72ac3efc96eaa44a8c4e/src/type.ts#L4) because @DanielRosenwasser suggested it to me last year. However, with this suggestion I have a namespace and a type with the same name if I want to use string literals and constants at the same time.

[RyanCavanaugh]

I recommend this approach: #3192 (comment)

[bobvanderlinden]

Even though string-based enums are now in TypeScript 2.4, it still is not possible to assign a literal string to an string-based enum (even though the value of the literal string matches a value of the enum). See the OPs example in TypeScript Playground.

It still fails on the following line:

const c2: Colors = "RED";

The example of OP is exactly the behavior I'd like to see: string literals and enum values being used interchangeably. It is however not yet possible.

Taking it a step further, the following should work as well:

enum ColorsEnum {
    Red = "RED",
    Green = "GREEN",
    Blue = "BLUE",
}

type ColorsType = 'RED' | 'GREEN' | 'BLUE';

const c1: ColorsType = 'RED';
const c2: ColorsEnum = c1;

Should a new issue be created or can we reopen this one?

[RyanCavanaugh]

@bobvanderlinden this is the intended behavior, not a bug. String enum values are intentionally opaque to consumers; if you want a non-opaque string type, you should use a literal union (i.e. ColorsType).

[bobvanderlinden]

@RyanCavanaugh Thanks for your reply. I guess we'll have to discuss some more on swagger-codegen which of the two to use (enums or unions).

[JoshuaKGoldberg]

@RyanCavanaugh IMO that's a limitation in the intended behavior that restricts the usage of string enums unnecessarily.

Consider how InversifyJS uses a literal union to specify settings. Because the existing behavior is to take in a string for some settings, the only way consumers can specify them in a type-safe manner is with string literals:

const container = new Container({
    defaultScope: "Singleton",
});

...but that means we can't use slightly-easier-to-get-intellisense-for enum members:

const container = new Container({
    defaultScope: BindingScope.Singleton,
});

Does that change your opinion?

Relevant issue: inversify/InversifyJS#706