And I do think there's a world where enum could be extended to support ADTs, e.g.:

enum Message {
  Quit,
  Write(text),
  Move({x, y}),
}

I'd still like to hear feedback as to what exactly is considered an anti-pattern regarding enum? The two things I've heard have been:

• Don't use enum in TS because it's not in ES
• enum defaulting to numbers and not something like Symbol()

Regarding Number vs String vs Symbol, my version of the proposal had a solution to that:

enum Color of String {
  Red, // "Red"
  Green, // "Geen"
  Blue, // "Blue"
}

enum Kind of Symbol {
  A, // Symbol("A')
  B, // Symbol("B")
}

enum BigFlags of BigInt {
  None, // 0n
  Flag1 = 1n << 0n,
  Flag2 = 1n << 1n,
}

// etc.

1. Enum's emit code - is irrelevant if enum exists natively
2. Numeric types unsafe - this has since been fixed
3. String ENUM's are named types - this does seem to be an odd behavior, though its specific to TS type checking and would be irrelevant to an ES enum

There is an issue with TS enum where there are a few cases where an enum member value's emit can be type-directed, but I think that's fixable in TS and wouldn't impact an ES enum.

do we need the of Type ? If an MVP was that the values had to be explicitly assigned, no auto-increment.

const MyFlags = enum {
   None: 0,
   A: 1,
   B: 2,
   AB: enum.A & enum.B
};

Also, the mechanism for explicit autonumbering as part of emit ends up not being truly "eraseable" as it requires the introduction of temporaries to handle initializers, i.e.:

import { x } from "./other.js";
enum E {
  A = x,
  B,
  C
}

This is also an example of the problematic type-directed emit in TS today that I hope to fix in the future. I cannot statically know what the value of x is without type checking, and thus could not reliably emit the auto-incremented values for B and C without additional overhead, i.e.:

var _a;
enum E {
  A = _a = x,
  B = ++_a,
  C = ++_a,
}

from enum import Enum, auto
class E(Enum):
  A = auto()
  B = auto()

The other benefit to a syntactic enum type would be future support for decorators for things like control over serialization, formatting, and marshalling, e.g.:

enum Position of Symbol {
  @JSONSerializer.Alias("emp")
  @JSONSerializer.SerializeAs("employee")
  Employee,

  @JSONSerializer.Alias("mgr")
  @JSONSerializer.SerializeAs("employee")
  Manager,

  ...
}

You can do something similar in Go as well:

type Foo int32
const (
  FooA E = 1 << iota // E(1)
  FooB // E(2)
  FooC // E(4)
)

Either way, not having auto numbering is incompatible with "erasable types" (i.e., such as ts-blank-space) as we have to inject initializers, or manually auto-number as in the example I mentioned above:

var _a;
enum E {
  A = _a = x,
  B = ++_a,
  C = ++_a,
}

I don't disagree, but I'm trying to thread the needle of:

• convenient syntax
• avoiding unnecessary compat risks
• aligning with "erasable types"
• fast math
• allowing non-numeric enumerated values

Potentially stupid question, but when we say "auto-increment should be opt-in", can it just be "opt-in" like this?

let counter = 0;
enum TokenType {
  Arrow = counter++,
  Identifier = counter++,
  ParenL = counter++,
  ParenR = counter++,
  // ...
}

Or, for binary flags,

let counter = 1;
enum TokenType {
  Arrow = counter <<=1,
  Identifier = counter <<=1,
  ParenL = counter <<=1,
  ParenR = counter <<=1,
  // ...
  Paren = ParenL | ParenR
}