Autoincrement on number and bigint

[Jack-Works]

In many languages enum can auto-increment its value:

enum E1 {
  X,
  Y,
  Z,
}

X, Y, Z equals 0, 1 and 2.

Problem

This is very useful in the development but this feature actually is a refactoring hazard and a foot gun.

When you add a new member in the middle, all following enum member value changes, that might cause API surface changes accidentally, break the application, or even introduce security bugs.

Flow.js does not allow autoincrement on number enums. All number enums must have an initializer to specify their value to prevent this foot gun.

Should we support autoincrement?

[michaelficarra]

Should we support autoincrement?

Absolutely not, for the reasons you mentioned.

[michaelficarra]

I remain unconvinced. "it is inconvenient for me to write a number that is one higher" is not a comparable concern to "it will cause people to accidentally break API compatibility all the time".

[rbuckton]

Not "write a number that is one higher", but rather, "insert a new item in a list, requiring renumbering every item that comes after it". I am also unsure how "break API compatibility" applies if you are using the enum declaration (i.e., Foo.Bar) rather than manually inlining a number value (which wouldn't work for Symbol or ADT enum types anyways).

I'm uncomfortable with imposing such a restriction on the entire JS developer community. If "no autonumbering" is a lint rule, you could at least explicitly opt-out by disabling the rule. If "no autonumbering" was just the default, a different mapper would let you explicitly opt-in.

[rbuckton]

I'd even be fine with an explicit syntax to opt in to auto-numbering, analogous to Python's auto() function:

enum E of number {
  auto X1,
  auto X2,
  auto X3,
}

Its more cumbersome than not having it at all, but addresses the maintenance concerns. However, I'm not sure how comfortable I would be with having number differ from symbol or string enums in this regard. In other words, it seems inconsistent to require auto in enum E of number { auto X } but not require it in enum E of string { X }.

[Jack-Works]

Explicitly opt-in autoincrement looks like a good tradeoff.

[ljharb]

Why would we want to make it easy to renumber a bunch of items at once? That's a breaking API change, and will almost certainly cause a plethora of bugs if permitted.

[hax]

Is it possible to leave that to decorator?

@autoinc enum E1 of BigInt { X, Y, Z }

[rbuckton]

My first guess is that decorator evaluation occurs too late for them to be used in this way. I would expect a decorator on enum E1 {} to see the fully evaluated E1, just like on a class.

[rbuckton]

Python enums support auto-numbering via a static auto method on the Enum base class, though Python enums do not have an enum-specific syntax. In https://github.com/rbuckton/proposal-enums, the behavior of an uninitialized enum member is determined by the "mapper" object passed to the of clause, which defines both the auto-numbering behavior for Number-like enums, as well as the value naming behavior for String and Symbol enums.