Enum declarations should consistently disallow computed keys

[nicolo-ribaudo]

Bug Report

🔎 Search Terms

• Computed property names are not allowed in enums
• enum declaration computed

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about enums

⏯ Playground Link

Playground link with relevant code

💻 Code

let y = "y";
type z = "z";

enum Foo {
    ['x'],
    [{}],
    [y],
    [z]
}

🙁 Actual behavior

TS reports Computed property names are not allowed in enums. for [{}], [y] and [z], while it allows ['x'] (in contraddiction with the error message).

🙂 Expected behavior

All of them should be an error, for the reason reported by the error.

📚 Context

This came up at babel/babel#12683: we can implement the current TS behavior in Babel, but I'd first like to check if TS is expected to report an error for ['x'].

[RyanCavanaugh]

The error message is underspecific; you can write [e] if e is exactly a numeric literal, string literal, or template literal with no holes.

I don't know why we added that logic 😕

[armano2]

is exactly a numeric literal

enum Foo {
    [1], // An enum member cannot have a numeric name. (2452)
}

it works only for "template literals without holes" and string literals

[RyanCavanaugh]

My prior comment was underspecific; you will not get that error message if the name is numeric 😅

[Zzzen]

The error message is underspecific; you can write [e] if e is exactly a numeric literal, string literal, or template literal with no holes.
I don't know why we added that logic 😕

To support keys containing special symbols? IMO, Dynamic property names are not allowed in enums. might be better.

[magic-akari]

With typescript-go on the horizon, I wanted to revisit this issue and propose a clear migration path.

Current State

This feature has extremely limited ecosystem support (ref):

• Babel, typescript-eslint, and SWC: None implement this syntax
• Real-world usage: Extremely rare (only sporadic bug reports despite years without support in these tools)

The bracket form is also semantically redundant—since only literal expressions are allowed (no [x] or ["a" + "b"]), ['\\t'] can always be replaced with '\\t'.

Proposal

Phase 1 (TypeScript): Add a deprecation warning with auto-fix

enum CHAR {
    ['\\t'] = 0x09,  // ⚠️ Computed property names are not allowed in enums
                     // 💡 Quick fix: Replace with '\\t' = 0x09
}

Phase 2 (typescript-go): Completely disallow bracket-style enum members

This aligns with:

• Existing ecosystem behavior (Babel, typescript-eslint, SWC)
• The original error message intent
• typescript-go's ability to make breaking changes for better language design

Impact

Minimal—the syntax is rarely used and can be mechanically migrated via auto-fix.

---

Would the team be open to this approach? Happy to help with implementation if there's interest.

[ahejlsberg]

I wouldn't be opposed to disallowing computed property names in enums altogether, particularly since that's the intent our error message already conveys. Agree with @RyanCavanaugh here, not sure why we permit it. That said, I hate to break stuff and I have no idea what the impact of disallowing it would be.