Reverse mapping

[Jack-Works]

The reverse mapping is the ability to get enum name from the enum value, for example, in TypeScript, you can do:

enum Enum {
  A,
}
 
let a = Enum.A;
let nameOfA = Enum[a]; // "A"

Problem

Should we support this use case?

This feature does not work well with inline-able (#4).

The TypeScript way only supports reverse mapping in number enum, if we want to support this use case, we should also support other kinds of enum.

[rbuckton]

In https://github.com/rbuckton/proposal-enum, reverse mapping was not via element access on the constructor, but via a static method on an Enum global (e.g., Enum.getName(E, value)). This provides the following benefits:

• No collision with a user-defined enum key of getName
• No collision with user defined enum keys and string enum values

[Jack-Works]

It's a bit strange to me. It will be better if the reverse mapping is stored on a symboled key like this:

enum A { A = 1 }

A[Symbol.reverseEnum][1] === 'A'

[ljharb]

Then A[Symbol.reverseEnum] is a separate object that has to be held for every enum. Would that object be mutable (normal, but probably bad for this use case), or immutable (super weird for the language, but matches the use case)? What [[Prototype]] would that object have?

I think a function-based API is the most straightforward - ideally, something that's not attached to the enum itself, but rather a single global function - eg if Enum.prototype is needed, then maybe Enum.lookup(A, 1) could look it up in an internal slot of A?

[Jack-Works]

I don't think Enum should have an internal slot. It should be like a normal userland object/record/struct.

All information needed for a reverse mapping is already on the enum object so it can be computed in runtime.

[Jack-Works]

There is another problem with reverse mapping. If multiple keys shared the same value, should reverse mapping return a list?

enum A { A = 1, B = 1 }
A[Symbol.reversEnum] // ["A", "B"]?