Repository navigation
Inconsistency between comment and implementation for enum computed property names #62649
Description
🔎 Search Terms
- enum
- computed
🕗 Version & Regression Information
- This changed between versions ______ and _______
- This changed in commit or PR _______
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________
- I was unable to test this on prior versions because _______
⏯ Playground Link
💻 Code
enum CHAR {
foo = 1, // ✅ Regular enum member
'\t' = 0x09, // ✅ String literal
"\n" = 0x0A, // ✅ String literal
['\v'] = 0x0B, // ✅ String literal within brackets
["\f"] = 0x0C, // ✅ String literal within brackets
[`\r`] = 0x0D, // ✅ Template literal (no substitution) within brackets
}
enum TEST {
`-` = 0, // ❌ Template literal outside brackets - Error TS2364
["a" + "b"] = 1, // ❌ Binary expression - Error TS1164
[`hello ${"world"}`] = 2, // ❌ Template literal with substitution - Error TS1164
}🙁 Actual behavior
The computed enum member is accepted by TypeScript
🙂 Expected behavior
Not sure
Additional information about the issue
Summary
While investigating how to properly handle enum computed property names in SWC (see swc-project/swc#11160), I noticed an inconsistency between the code comment and the actual implementation in TypeScript's compiler.
The Issue
In types.ts:3601-3608, the comment states:
export interface EnumMember extends NamedDeclaration, JSDocContainer {
readonly kind: SyntaxKind.EnumMember;
readonly parent: EnumDeclaration;
// This does include ComputedPropertyName, but the parser will give an error
// if it parses a ComputedPropertyName in an EnumMember
readonly name: PropertyName; // PropertyName includes ComputedPropertyName
readonly initializer?: Expression;
}However, the actual behavior differs from this comment:
- The parser does NOT emit errors for computed property names with literal expressions like
["\t"]or[`hello`] - Validation actually happens in the type checker (
checker.ts:47808), which only rejects non-literal computed expressions
Example
This code is accepted by TypeScript:
enum CHAR {
['\v'] = 0x0B, // ✅ String literal within brackets - accepted
["\f"] = 0x0C, // ✅ String literal within brackets - accepted
[`\r`] = 0x0D, // ✅ Template literal (no substitution) within brackets - accepted
}While this is rejected:
enum TEST {
["a" + "b"] = 1, // ❌ Binary expression - Error TS1164
[`hello ${"world"}`] = 2, // ❌ Template literal with substitution - Error TS1164
}Question
There's a clear inconsistency between the comment and the implementation. Could you clarify which one reflects the intended design?
Understanding the intended behavior would help us implement the correct handling in SWC.
Thank you for your time!
Activity
magic-akari commentedon Oct 21, 2025
Following up on this issue, I wanted to share some context that might be helpful for deciding how to handle this inconsistency.
Ecosystem Context
While investigating this for SWC, I noticed an interesting pattern:
This limited adoption aligns with what Brad Zacher (@bradzacher) from typescript-eslint observed—despite not supporting it, they haven't received bug reports.
Question for the Team
Given this context, I'm curious about the intended direction for this feature:
I noticed #42468 has been open since 2021, which suggests this has been a long-standing question. With typescript-go on the horizon, this might be a good opportunity to establish a clear direction. But I wanted to understand TypeScript's perspective first before making any decisions for SWC.
Thanks for any guidance you can provide!
RyanCavanaugh commentedon Oct 21, 2025
Anders Hejlsberg (@ahejlsberg) IMO the comment is just slightly off. Thoughts?
RyanCavanaugh commentedon Oct 22, 2025
magic-akari commentedon Oct 22, 2025
Closing in favor of #42468.