sugar for enum

Hi All,

Just wanted to humbly ask for reconsideration of GitHub - tc39/proposal-enum: Proposal for ECMAScript enums. I've been using NodeJS v24 recently and I am loving the typescript stripping. But enums are a pain. You gave us syntactic sugar for class and async/await ... how about enum please - it will reduce much heartache.

Thanks

Neither class and async/await are purely syntactic sugar, fwiw.

They have almost equivalents with functions+WeakMaps & Promises though. Maybe you need to smooth some edges but I don't think there are inherent capabilities gained?

For class, extending builtins installs internal slots, a previously unavailable capability, and private fields is also very much a new capability (altho true, it's mostly sugar for a closed-over WeakMap, which wasn't available prior to class being available); for await, the amount of runtime code you need to emulate generators in order to support await inside a loop (regenerator-runtime) is sufficiently prohibitive that i don't think "sugar" really holds.

Either way, enum isn't "rejected" or anything, so it doesn't require "reconsideration" - just a champion with the time to do the work to drive it forward.

it will reduce much heartache.

Can you give an example?

From my experience, I've learnt to reject enums a while ago and embrace type unions, which give you the same type safety, but with less verbosity, and they vanish in the final bundle.

Enums have been born as a mnemonic and semantic way to describe special values, that assume special meaning in some contexts but are often represented with integers due to memory or performance constraints. But that's hardly a problem in 2025. What's your use case for enums today?

The proposal you've linked doesn't sound very charming IMO: you can do most of that stuff with classic object literals. It shows its most interesting parts in the "future" additions. But they hardly resemble "classic" enums at that point.