Repository navigation
Reverse Enum Member Initialization Order for Constants #12693
Description
Consider the following enum.
enum A {
Name,
LongName,
ReallyLongName
}It's javascript output is
var A;
(function (A) {
A[A["Name"] = 0] = "Name";
A[A["LongName"] = 1] = "LongName";
A[A["ReallyLongName"] = 2] = "ReallyLongName";
})(A || (A = {}));but would be much more succinct if it were output as
var A;
(function (A) {
A[A[0] = "Name"] = 0;
A[A[1] = "LongName"] = 1;
A[A[2] = "ReallyLongName"] = 2;
})(A || (A = {}));The only benefit to this change would be minification of the output javascript. Running the two versions in a minifier I'm getting the current output minified at 116 bytes and the proposed way at 96 bytes for a difference of about 17%. Obviously, this difference would be influenced by the number of enum members and the length of the enum members' names.
This change would only be applicable to enum members with a constant value.
Activity
mhegazy commentedon Dec 6, 2016
this assumes a side-effect free initialization expressions. consider:
with getters being part of the language, any property access can not guaranteed to be side-effect free, so we would have different emit for enums with auto-initialized members or const-expression-initialized, vs. ones with non-const-expression-initialized enums.
why not use
const enumsinstead?DanielRosenwasser commentedon Dec 6, 2016
Mohamed Hegazy (@mhegazy)
const enums are early-bound which is not always desirable for dependencies whoseenums should be late-bound. If you usepreserveConstEnumsto hack around that for consumers (like we do), you still run into the same exact problem.Precisely - the suggestion here is for enums which are known to be const-initialized and side-effect free, something we already have means of tracking.
RyanCavanaugh commentedon Jan 24, 2017
It'd be a runtime breaking change to do this because enums with duplicate values would reverse map to a different name in this emit.
const enumremains the best option for size-conscious codebases.