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

[anurbol]

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.

[AnyhowStep]

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;

[anurbol]

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)..

[forivall]

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

[AnyhowStep]

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

[mperktold]

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.

[jhnns]

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.

[nbabanov]

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

[forivall]

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.