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

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

https://github.com/microsoft/TypeScript/issues/31834

https://github.com/microsoft/TypeScript/issues/30629

https://github.com/microsoft/TypeScript/issues/26362

https://github.com/microsoft/TypeScript/issues/22464

https://github.com/microsoft/TypeScript/issues/22311

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;

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. :(

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.

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

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

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! 🎊

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