emit an error when using #private fields in their "temporal dead zone"

[trusktr]

🔍 Search Terms

error for private member accessed before ready

✅ Viability Checklist

• [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [X] This wouldn't change the runtime behavior of existing JavaScript code
• [X] This could be implemented without emitting different JS based on the types of the expressions
• [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [X] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• [X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

This produces a runtime error when you run it:

abstract class Base {
  constructor() {
    this.createStuff()
  }

    abstract createStuff(): void
}

class Sub extends Base {
    #makeSomething() {
        console.log('make stuff')
    }

    createStuff() {
        this.#makeSomething()
    }
}

// TypeError: Cannot read private member from an object whose class did
// not declare it (JavaScript points finger at you while laughing)
new Sub().createStuff()

playground

📃 Motivating Example

It has happened to me too many times due to subclass code running early before initialization of private fields.

Unfortunately the simple solution is to avoid class fields for this case (use properties-defined-in-constructor, or getters).

💻 Use Cases

Sometimes we want a constructor to make stuff generically for subclasses, but then subclasses should override or implement some methods to replace certain parts.

I believe there is enough static info that it would be possible to check for this case and emit a compile error.

Similarly it would also be possible to enforce non-private fields to be | undefined when used early in a location that is known to be called before initialization (f.e. in a superclass constructor).

[fatcerberus]

Related to #9998 because this would require control flow analysis to recursively follow function/method/constructor calls.

[fatcerberus]

A rule that might work without requiring deep CFA would be to completely disallow calling abstract methods in the constructor, under the assumption that they could make use of private fields in a subclass. That might be too breaky, though, and also wouldn’t catch non-abstract calls that are overridden in a subclass.

[RyanCavanaugh]

The C++ wisdom from the 90's was that you should never invoke any virtual behavior from the constructor (precisely because the derived class constructor hasn't run yet), abstract being the worst-case scenario for that rule, but this was never enforced by the compiler, presumably for the same CFA inlining reasons. Kids these days, amirite?