Allow Infinity, -Infinity and NaN as an enum key name for string enum

[XeroAlpha]

🔍 Search Terms

infinity nan enum string

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Allow the usage of Infinity, -Infinity, and NaN as key names in a string enum.

I understand the reasoning behind disallowing numeric names as enum keys, as they can cause conflicts with reverse mapping.
However, in the case of a string enum where every value is a string, reverse mapping is not applied. Therefore, it does not make sense to disallow numeric names in this scenario.

📃 Motivating Example

enum SomeEnum {
    Infinity = 1, // This should fail!
    Apple = Number.POSITIVE_INFINITY,
}

enum MinecraftEnchantmentTypes {
    Infinity = 'infinity', // This should pass!
    Unbreaking = 'unbreaking'
}

💻 Use Cases

1. What do you want to use this for?
   To maintain compatibility with existing code.

2. What shortcomings exist with current approaches?
   Please refer to the suggestion provided.

3. What workarounds are you using in the meantime?
   Currently, there are no workarounds available except renaming enum members, which would introduce breaking changes.

[MartinJohns]

This was allowed before, but then it was intentionally removed again: #56161

[RyanCavanaugh]

I don't think this rule makes sense to apply to string enums. Will discuss.

[DanielRosenwasser]

It's not purely about string enum members. It depends entirely on whether other members contribute a reverse mapping that could conflict:

Playground Link

enum E {
    Infinity = "boop",
    blah = 1/0,
}

console.log(E.Infinity); // prints "blah", not "boop"!

I other words, we need to keep the keys and reverse-mapping keys disjoint so one doesn't stomp on the other.

There's basically two ways of relaxing this:

1. numerically named string enum members are allowed if all members of an enum are string-based
2. numerically named string enum members are allowed if no other enum member contributes a conflicting reverse mapping

(1) is just a heavier restriction of (2) because it'll be vacuously true - there will never be any conflicting reverse mappings because there won't be any to begin with on an all-string enum.