Repository navigation
Enum declarations should consistently disallow computed keys #42468
Description
Bug Report
🔎 Search Terms
Computed property names are not allowed in enumsenum 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'].
Activity
RyanCavanaugh commentedon Jan 26, 2021
The error message is underspecific; you can write
[e]ifeis exactly a numeric literal, string literal, or template literal with no holes.I don't know why we added that logic 😕
armano2 commentedon Jan 26, 2021
it works only for "template literals without holes" and string literals
RyanCavanaugh commentedon Jan 26, 2021
My prior comment was underspecific; you will not get that error message if the name is numeric 😅
Zzzen commentedon Jul 12, 2021
To support keys containing special symbols? IMO,
Dynamic property names are not allowed in enums.might be better.add suggestion diagnostic for enum computed string keys (microsoft#42468
magic-akari commentedon Oct 22, 2025
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):
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
Phase 2 (typescript-go): Completely disallow bracket-style enum members
This aligns with:
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 commentedon Oct 22, 2025
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 Ryan Cavanaugh (@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.
Deprecate literal computed property names in enums
Deprecate literal computed property names in enums