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

#31834

#30629

#26362

#22464

#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;

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.