computed keys with private element and super call should not be hoisted when targeted to ES2022

[JLHwung]

🔎 Search Terms

Private element, computed key, super call

🕗 Version & Regression Information

• This is a crash
• This changed between versions ______ and _______
• This changed in commit or PR _______
• This is the behavior in every version I tried, and I reviewed the FAQ for entries about Classes
• I was unable to test this on prior versions because _______

⏯ Playground Link

https://www.typescriptlang.org/play?target=9#code/DYUwLgBAxghgDmArgJxAEwGIHssEEpQgDORANBKkYsGANwBQUwMJEAQhAN70TRYB2RMMkRQwWZAAoAbgEouPXtHhJUmHPkKsAvBGmKAvvSP1+IAO7RmrAMIQQADzAh+aIuwW8oAoSLETJeW4lKxZ3XE8QiCEYMABLKAgAYgAzHAhdABYAJgYo6LBYhIgAbSo4EClJMHltAD4IMAA6VJxZAF08pQMu3kpqSF1YBBR0bDwCYiJJXFlaXkNjekYfLFAm4CwAc0lOCmIBiAM5oA

💻 Code

let capturedFooAccess, result;
class B {
 constructor(v) {
 capturedFooAccess = v
 }
}

new class C extends B {
 constructor() {
 class A {
 static #foo = 42;
 static [super((t) => t.#foo)];
 };
 result = capturedFooAccess(A); 
 }
}

console.log({ result });

🙁 Actual behavior

The transformed code throws "Private field '#foo' must be declared in an enclosing class" because the private key IIFE is hoisted before class A.

🙂 Expected behavior

It should print { result: 42 }

The input is already ES2022, TS could have left it as-is.

Additional information about the issue

We can dodge this issue in ES2022 target, but I haven't figured out how to deal with the decorator expression. Either we lost the #foo access or the super() is moved to the scope of the underived class A.

let capturedFooAccess, result;
class B {
 constructor(v) {
 capturedFooAccess = v
 }
}

new class C extends B {
 constructor() {
 class A {
 @(super((t) => t.#foo), v => v) #foo = 42;
 };
 result = capturedFooAccess(A); 
 }
}

console.log({ result });

[fatcerberus]

It should print { result: 42 }

The input is already ES2022, TS could have left it as-is.

That's the behavior I'm observing:
https://www.typescriptlang.org/play?target=9&filetype=js#code/DYUwLgBAxghgDmArgJxAEwGIHssEEpQgDORANBKkYsGANwBQUwMJEAQhAN70TRYB2RMMkRQwWZAAoAbgEouPXtHhJUmHPkKsAvBGmKAvvSP1+IAO7RmrAMIQQADzAh+aIuwW8oAoSLETJeW4lKxZ3XE8QiCEYMABLKAgAYgAzHAhdABYAJgYo6LBYhIgAbSo4EClJMHltAD4IMAA6VJxZAF08pQMu3kpqSF1YBBR0bDwCYiJJXFlaXkNjekYfLFAm4CwAc0lOCmIBiAM5oA

[JLHwung]

That's the behavior I'm observing: https://www.typescriptlang.org/play?target=9&filetype=js#code/DYUwLgBAxghgDmArgJxAEwGIHssEEpQgDORANBKkYsGANwBQUwMJEAQhAN70TRYB2RMMkRQwWZAAoAbgEouPXtHhJUmHPkKsAvBGmKAvvSP1+IAO7RmrAMIQQADzAh+aIuwW8oAoSLETJeW4lKxZ3XE8QiCEYMABLKAgAYgAzHAhdABYAJgYo6LBYhIgAbSo4EClJMHltAD4IMAA6VJxZAF08pQMu3kpqSF1YBBR0bDwCYiJJXFlaXkNjekYfLFAm4CwAc0lOCmIBiAM5oA

Oh I didn't realize that there is one more requirement for reproduction: The language option should be set to "TypeScript", (yours is JavaScript).

[fatcerberus]

I noticed that; choosing TS changes the emit. That's almost certainly a bug.

[JLHwung]

Oh it is a TS-only issue because when I enable the useDefineForClassFields option, the output is good.

[IllusionMH]

It (uDFCF) should be enable in tsc by default for targets es2022+ IIRC but, unfortunately, there is no "default" switch of this flag in playground and it's should be set manually in playground.

[rbuckton]

We currently report an error if you use this in a class element computed property name as it could be considered ambiguous as to which this you are referring. We should also make it an error to refer to super for the same reason.

When useDefineForClassFields is false, we have to move some things around to ensure we preserve evaluation order. This means evaluating some things in a static {} block as we try to avoid injecting logic into computed property names as it produces unreadable code. While the emit here is definitely a bug, it's a bit complicated to produce the desired output here using static {}, as moving the arrow that captures super into a static {} block would change its meaning.

What we would have to emit to preserve scoping and evaluation order would be something like this:

"use strict";
let capturedFooAccess, result;
class B {
 constructor(v) {
 capturedFooAccess = v;
 }
}
new class C extends B {
 constructor() {
 var _a;
 _a = (...args_1) => super(...args_1); // lexical `super` capture
 class A {
 static { _a((t) => t.#foo); } // evaluation before initializers are run

 static #foo = 42;
 }
 ;
 result = capturedFooAccess(A);
 }
};
console.log({ result });

This seems like a somewhat superfluous transformation; however, if you modify the example to include an initializer for the static field with the computed name (e.g., static [super(...)] = 1), it becomes far more evident why we would do this kind of transformation:

"use strict";
let capturedFooAccess, result;
class B {
 constructor(v) {
 capturedFooAccess = v;
 }
}
new class C extends B {
 constructor() {
 var _a, _b;
 _b = (...args_1) => super(...args_1); // lexical `super` capture
 class A {
 static { _a = _b((t) => t.#foo); } // evaluation and capture of property name before
 // initializers are run

 static #foo = 42;
 static { this[_a] = 1; } // Set-based initialization of static field
 }
 ;
 result = capturedFooAccess(A);
 }
};
console.log({ result });