Should not allow numeric names on enum members

[JsonFreeman]

Because of the way the codegen works for enums, we really do not emit sensible code when the enum members have numeric names. Consider this innocent looking example (compiler gives no errors here):

enum E {
    1, 2, 3
}

console.log([E[1], E[2], E[3]].join(',')); // Prints 2,3,2 instead of 0,1,2
console.log(E[1].toExponential()); // Crash
console.log(E[2].toExponential()); // Crash
console.log(E[3].toExponential()); // Prints 2e+0

Codegen:

var E;
(function (E) {
    E[E["1"] = 0] = "1";
    E[E["2"] = 1] = "2";
    E[E["3"] = 2] = "3";
})(E || (E = {}));

console.log([E[1], E[2], E[3]].join(','));
console.log(E[1].toExponential());
console.log(E[2].toExponential());
console.log(E[3].toExponential());

So my question is why do we allow numeric names in an enum, if we cannot emit it right. We can explain to users the semantics for an enum, but our codegen for this pretty confined construct doesn’t adhere to those semantics, and it crashes! Also, an enum with numeric member names does not correspond to an existing javascript pattern that we want to support. I don’t see any reason for this to be allowed.

I realize this is a breaking change. Do people have objections to this break?

[JsonFreeman]

To emphasize, while this is not a serious issue in terms of its impact, enums are a prepackaged typescript concept (not a javascript pattern), and in this case, we do not emit them in a way that matches our own semantics for them.

[RyanCavanaugh]

Seems ready to discuss.

[RyanCavanaugh]

Discussed in design meeting and approved.

[chrisbubernak]

Did anyone end up working on this? I've looked into it a bit and the fix seems pretty straight forward, the more tedious aspect is going to be cleaning up a good chunk of test cases that all use the following Enum:

enum ENUM1 { 1, 2, "" };

Anyways if we still want this done and no one picked it up I'll give it a shot.

[mhegazy]

Thanks @chrisbubernak. Please proceed with your PR.