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.