Simpler desugaring without problematic semantics

[erights]

Let's start with the following variation of the original example.

enum E {
  A = 1,
  B = A + f(E).C,
  C = 3,
}

Applying the original desugaring to it, we get

let E = (() => {
  let E = Object.create(null), A, B, C;
  Object.defineProperty(E, "A", { value: A = 1 });
  Object.defineProperty(E, "B", { value: B = A + f(E).C }); // NaN
  Object.defineProperty(E, "C", { value: C = 3 });
  Object.defineProperty(E, Symbol.iterator, {
    value: function* () {
      yield ["A", E.A];
      yield ["B", E.B];
      yield ["C", E.C];
    }
  });
  Object.defineProperty(E, Symbol.toStringTag, { value: "E" });
  Object.preventExtensions(E);
  return E;
})();

This has several problems:

• f(E) is called before E is fully initialized, making E available in its uninitialized state.
• Even if f were the identity function, or if we had written A + E.C instead, we'd be getting the value of the C property before it is defined. Our normal expectation should be a thrown TDZ error. Instead, it silently initializes E.B to 1 + undefined, which is NaN.

By the simpler desugaring this issue proposes to use instead, it would desugar to

const E = (() => {
  const A = 1;
  const B = A + f(E).C; // TDZ
  const C = 3;
  return Object.freeze({ __proto__: null, A, B, C });
});

which does produce the TDZ programmers should expect, rather than making E available to user code before it is fully initialized, and rather than mistakenly but silently initializing E.B to NaN.

Even the simpler example

enum E {
  A = 1,
  B = A + C,
  C = 3,
}

would still silently set B to NaN in the original desugaring, whereas it would throw a TDZ error in the desugaring we propose here.

The unproblematic way to express the intent of the original example

enum E {
  A = 1,
  B = 2,
  C = A | B, // 3
}

would work identically under both desugarings. In the simpler desugaring proposed here, it desugars to

const E = (() => {
  const A = 1;
  const B = 2
  const C = A | B;
  return Object.freeze({ __proto__: null, A, B, C });
});

What about TypeScript interoperation?

Unproven claim

Any enum declaration that does not throw under the simpler desugaring would not throw under the original desugaring with no observable difference between the two.

We are indeed uncertain about this. Please try to find a counter-example.

Assuming this claim is true, and assuming the original desugaring accurately captures the semantics of the TypeScript compiler's desugaring, then adopting this simpler desugaring into the JS standard is well aligned with the goals of so-called "Erasable TypeScript" systems like ts-blank-space or Node's --experimental-strip-types option. "Erasable TypeScript" would be a subset of full TypeScript where programs that work in Erasable TypeScript also work in full TypeScript with the same meaning.

Erasable Typescript would thus be able to grow to include such enum declarations.

[erights]

At example in TS playground we see that

enum E {
  A = 1,
  B = A + f(E).C,
  C = 3,
}

in the actual TypeScript compiler, desugars to

var E;
(function (E) {
    E[E["A"] = 1] = "A";
    E[E["B"] = E.A + f(E).C] = "B";
    E[E["C"] = 3] = "C";
})(E || (E = {}));

which is observably more different to either the desugaring proposed by this proposal and to the simpler desugaring proposed by this issue. Compared to these differences with actual TypeScript, the observable differences between the proposal's desugaring and this issue's desugarings are minor. In particular, the differences with actual TypeScript will be apparent to normal non-edge-case code.

Thus, we should not favor the proposal's desugaring over this issue's based on fidelity to existing TypeScript semantics.

[littledan]

On one hand, from first principles, I definitely like @erights 's idea here. At the same time, it might be too annoying to use in practice (I don't have enough experience with enums to have a strong intuition one way or another). Consider that, for static fields, we decided to allow references to the partially-initialized class. Maybe this is a similar case.

[erights]

I'd like to propose an orthogonal enhancement to any of these desugarings. But for simplicity I'll illustrate with my preferred desugaring.

First, assume a new (perhaps anonymous) primordial intrinsic:

const __EnumNotFoundProxy__ = new Proxy(
  Object.freeze({__proto__: null}),
  Object.freeze({ // the handler is not actually accessible, so whether it is frozen is not observable
    get(_, prop) {
      throw ReferenceError(`enum name ${String(prop)} not found`); // or TypeError?, RangeError?
    },
  }),
);

then

enum E {
  A = 1,
  B = 2,
  C = A | B,
}

desugars to

const E = (() => {
  const A = 1;
  const B = 2
  const C = A | B;
  return Object.freeze({ __proto__: __EnumNotFoundProxy__, A, B, C });
});

Without this enhancement, in any of the desugarings, E.X would return undefined. With the enhancement, E.X would throw an appropriate error.

Thanks @turadg for suggesting this throwing behavior for this case.

Again, this enhancement is independent of which desugaring semantics we start with.