Enums behave unexpectedly, the workaround is verbose. There should be a less verbose way.

Search Terms

enums

Suggestion

Because enums do not work as expected...

const enum MyEnum {
    Zero, 
    One
} 

const foo: MyEnum.Zero = 0 // Ok as expected (since MyEnum.Zero is zero)
const bar: MyEnum.Zero = 1 // OK, but expected Error!

...people start using this workaround (aka "namespace-as-enum"):

namespace MyEnum {
  export const Zero = 0;
  export type Zero = typeof Zero;

  export const One = 1;
  export type One = typeof One;
}
type MyEnum = typeof MyEnum[keyof typeof MyEnum];
const foo: MyEnum.Zero = 0 // okay as expected
const bar: MyEnum.Zero = 1 // error as expected

Maybe there should be a less verbose way to do this common stuff?
For example it could be something like enum MyEnum {type Zero, type One}

Use Cases

I use number values (i.e. enums) extensively instead of string values for performance reasons (a lot of JSON.stringify/parse).

Examples

// Syntax A...
const enum MyEnum {
    type Zero,
    type One
} 
// ...or syntax B (C++ style) 
const enum class MyEnum {
    Zero, 
    One
} 

const foo: MyEnum.Zero = 0 // Ok 
const bar: MyEnum.Zero = 1 // Error!

C++ had the same problem and they fixed it

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.

Please don't close this issue as "working as intended" or "question" or "won't fix". At the very least, leave it open so people can vote on it.

It's pretty annoying that enums are basically just number just to support bit masks/flags when that's not what an enum is really supposed to be

There are probably a bunch of other issues related to this.

The point being that enums, as they are now, are only really useful if you use bit masks and don't care about variables of that type being any number.

However, that runs counter to how one usually thinks about enums. If anything, people that use bitwise operators on numeric enum values should get back a number that is not assignable to the original enum type.

If backwards compatibility for this thing is so important, then, as above, new syntax for "proper" enums should be introduced that's a shorthand for the namespace-as-enum workaround.

I don't have hard numbers but I feel like most people who use numeric enums expect it to behave like the namespace-as-enum workaround.

Whenever someone asks me why their enum code isn't working (at work, on gitter, where ever), I just tell them because enums are broken and to not use them. It would be nice to have it unbroken

Maybe introduce syntax like enum class (like in c++).
Except, cpp enum classes are a little too restrictive.

It would be nice if TS enum classes would have the behavior of the namespace-as-enum workaround.

//Maybe call it `enum namespace`? `enum interface`?
enum class MyEnum {
  Zero,
  One,
}
//OK
const x : MyEnum.One = 1;
//Error
const y : MyEnum.One = 0;

//OK
const a : 1 = MyEnum.One;
//Error
const b : 1 = MyEnum.Zero;

//Error
const e : MyEnum = 2;

Yep, we only need a syntax sugar (I know it might be much harder done than said) for the namespace-as-enum workaround. The behavior of the workaround should remain (it works 100% fine)..

i think the --preserveConstEnums compiler flag can be used for that, although I haven't used it. It's worth investigating

Anyway, one reason for wanting a new type of enum is because the current enum type does not reflect the actual run-time values.

enum Test {
    One = "one",
    Two = "two"
}

//Expected: "one"
//Actual  : never
type strExtractEnum = Extract<"one", Test.One>

//Expected: Test.One
//Actual  : Test.One
type enumExtractStr  = Extract<Test.One, "one">

//Expected: OK
//Actual  : Error
const e : Test.One = "one";
//Expected: OK
//Actual  : OK
const s : "one" = Test.One;

//"one"
console.log(Test.One);
//"one"
console.log("one");
//true
console.log("one" === Test.One);

Playground

This behavior is really counter-intuitive.

The TypeScript handbook itself states that if all enum members are initialized to a static value,

... enum types themselves effectively become a union of each enum member. While we haven’t discussed union types yet, all that you need to know is that with union enums, the type system is able to leverage the fact that it knows the exact set of values that exist in the enum itself.

This is simply not true, but I wish it was.

What concerns me the most is that this behavior is in conflict with certain type inference rules such as exhaustiveness checking when using strictNullChecks.

For example, the following is considered exhaustive, but in reality isn't:

enum Direction { Left = 1, Right = 2 }

function directionName(dir: Direction): string {
  switch (dir) {
    case Direction.Left:  return "left";
    case Direction.Right: return "right";
  }
}

// both calls return undefined, even if that shouldn't be possible
console.log(directionName(Direction.Left | Direction.Right));
console.log(directionName(42));

I was aware that you can use enums as bit flags and combine them using bitwise logic operators, but I assumed that the compiler somehow distinguished between the two cases based on some conventions.

For example, it could activate bit flag behavior only if all constants are initialized to a single bit or a combination of other constants, and otherwise fallback to a strict union type of all constants.

enum DirectionFlags {
  // single bits
  Up    = 1 << 0,
  Right = 1 << 1,
  Down  = 1 << 2,
  Left  = 1 << 3,
  // predefined combinations
  UpRight   = Up | Right,
  DownRight = Down | Right,
  DownLeft  = Down | Left,
  UpLeft    = Up | Left
}

It really think it would be much safer and more convenient to only allow bit flag usage if the enum definition meets certain conditions, to make sure it really was intended to be used in this way.
Also, I don't think flags are used very often.
And of course, a distinction on the syntax level would be even better.

I understand that changing the behavior of enums breaks backward compatibility.
On the other hand, perhaps a large number of developers have an incorrect intuition of how enums work, so maybe the change fixes more than it breaks.

Just stumbled upon this and I have to say that I'm really surprised about the current behavior. To me, the keyword enum clearly communicates that only the enumerated values are allowed, not just all numbers. And what's even more surprising is that enums do work as expected with strings. They're even super-strict with strings, treating enum members effectively as symbols:

enum State {
    Success = "SUCCESS",
    Error = "ERROR",
}

const state: State = "SUCCESS"; // Error, because it's not State.Success
                                // This is how symbols work

To me, this behavior is very unexpected and also inconsistent. And given the long list of issues (#17734, #21546, #11559, #15591, #8020, #18409, ...) I'm not the only one that finds that surprising.

I do understand that this is a massive breaking change, especially for the TypeScript project itself. But I think that this needs to be addressed somehow. I honestly never used bit masks in my projects, but I do use enums all the time and there are a lot of places where I relied on the exhaustiveness check (which clearly doesn't work as you can pass in any number).

What about a symbol enum or enum symbol keyword:

enum symbol State {
    Success,
    Error,
}

// Syntactic sugar for:

const State = {
    Success: Symbol("Success") as unique symbol, // as unique symbol is currently not
    Error: Symbol("Error") as unique symbol,     // allowed but you probably get the gist :)
};

type State = typeof State.Success | typeof State.Error;

let state: State;
state = State.Success; // Works
state = "Success"; // Error, because it must be the State.Success symbol

This would also be a good trade-off between easy to write enums that do not require you to re-spell the string literal (as string enums currently do) while maintaining debuggability because of symbol descriptions.

I would also appreciate a proper fix for the enums. As they stand now, they seem a bit useless.

enum MyEnum {
	B = 3
}

function foo(param: MyEnum) {    
}

foo(MyEnum.B); // This should be the only working example.

foo('asdfasdf'); // This does not work, which is good.

foo(2); // This should also not work, but it does. :(

For the case in #32690 (comment)

//Expected: "one"
//Actual  : never
type strExtractEnum = Extract<"one", Test.One>

A workaround for this is in the following gist: https://gist.github.com/forivall/8968ec4ef450ceac9949b3a25583ca6d It leverages the behaviour that an enum can be treated as a const value, and makes it work the other way around.

I went with this:

const roles = {
  DSCO: 0x1 as 0x1,
  AIDE: 0x2 as 0x2,
  LT: 0x4 as 0x4,
  FF: 0x8 as 0x8,
  CHIEF: 0x12 as 0x12,
};
type Role = keyof typeof roles;
type RoleAsInt = typeof roles[keyof typeof roles];

It isn't completely DRY but it's close: the repetition is short and contained to each line. Would love some feedback.

hoclun-rigsep

hoclun-rigsep you can write as const on the outside instead of as 0x1 on each line

Amazing! Cuts down on the RY. Already glad I posted.

I'm surprised there isn't a simple way to create a typesafe enum distinct from number. isn't the whole point of typescript to add type-safety to javascript? allowing arbitrary values to be assigned to an enum-typed value seems contrary to this goal.

The whole "bit bitfields are convenient" argument seems specious - assigning a number to a string is convenient, but wrong. using enums like this is a C-ism - fixed in C++.

Current:

enum EnumTest {
    One = 1, // => typeof EnumTest.One in compile time: EnumTest.One (alias for number), runtime: number
    Two = "two",  // => typeof EnumTest.Two in compile time: EnumTest.Two (alias for some type be treated as Symbol('two')), runtime: string
}

=> It clearly leads to an unsafe type as in many cases above.

Suggestion:

enum EnumTest {
    One = 1, // => typeof EnumTest.One in compile time: EnumTest.One (alias for 1), runtime: number
    Two = "two",  // => typeof EnumTest.Two in compile time: EnumTest.Two (alias for 'two'), runtime: string
}

Current solution:

Never use "enum" with the initial value as a number (it is not a safe type). Use string initial instead of, the problem here just is we can't directly assign a string value to a variable had enum type

Daniel Rosenwasser (@DanielRosenwasser)

Daniel Rosenwasser (@DanielRosenwasser) Hey Dan, what do you think about this issue? A lot of people have to write more verbose code because of this.

Bumped into this today as well, just for the record.

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@RyanCavanaugh) Any breakthrough here?

enum MyEnum {
	B = 3
}

function foo(param: MyEnum) {    
}

foo(MyEnum.B); // This should be the only working example.

foo('asdfasdf'); // This does not work, which is good.

foo(2); // This should also not work, but it does. :(

Seems like this is finally fixed in TypeScript v5!

Thanks a lot for the work! 🎊

Navigation Menu

Repository navigation

Enums behave unexpectedly, the workaround is verbose. There should be a less verbose way. #32690

Search Terms

Suggestion

Use Cases

Examples

Checklist

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Enums behave unexpectedly, the workaround is verbose. There should be a less verbose way. #32690

Description

Search Terms

Suggestion

Use Cases

Examples

Checklist

Activity

AnyhowStep commented on Aug 3, 2019

anurbol commented on Aug 3, 2019

forivall commented on Aug 10, 2019

AnyhowStep commented on Sep 5, 2019

mperktold commented on Dec 6, 2019

jhnns commented on Dec 21, 2019

nbabanov commented on Jun 22, 2020

forivall commented on Jun 22, 2020

hoclun-rigsep commented on Jul 8, 2021

RyanCavanaugh commented on Jul 8, 2021

hoclun-rigsep commented on Jul 8, 2021

Spongman commented on Jun 27, 2022

hoangfnv commented on Jul 26, 2022

nbabanov commented on Aug 25, 2022

mkarajohn commented on Sep 1, 2022

nbabanov commented on Sep 2, 2022

nbabanov commented on Apr 6, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions