private fields in nested classes should have separate types?

[trusktr]

🔍 Search Terms

typescript private field nested class

✅ Viability Checklist

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

⭐ Suggestion

Private fields of a wrapper class are similar to symbols: perhaps the nested classes could have their own types for the fields based on the value they initialize in their constructor:

📃 Motivating Example

https://www.typescriptlang.org/play/?noImplicitAny=false#code/MYGwhgzhAEBiBOBLApgOwCYwN4CgCQAxAG5ggCuyO+sA9jdALzSiQy33IAeALmpnEj7Z8eYDVQRu8MsG414ACgCU0XHnUQyAB2SKlIvNwAWiCADpipCo2gAWAKwA2aAHoX0ADwBaH779foVDIAWwAjXREAXyp1ADM6AFlkYxp0ZVUDMQkaEGQzEBoAcwVjUwsScmR9dWi8aPwAITB4GxYoaCaWrl4MGFLzdgz1LMlpWXl0tQ1tXWUDfvKrZBsAIgB2AA4AThXXd29-Q59oUcRUQqiYvFDmpJS0lSnRcQgcvILihctK6rr8aPqI24qnYABoOs1IjZUMgAO4CFC9OY4IHQWLQuFwOhzVGhDHwzrI2JmeI0O5GVLpNzQD4wFYORwrHChMw3eDkykqam06DrbYrIA

Plain JS:

class Friends {
	#priv

	Foo = class Foo extends Friends {
		constructor() {
			super()
			this.#priv = 456 // <----------- number
		}

		fooMethod() {
			console.log(this.#priv)
		}
	}

	Bar = class Bar extends this.Foo {
		constructor() {
			super()
			this.#priv = "789" // <-------------- string
		}

		barMethod() {
			console.log(this.#priv)
		}
	}
}

const {Foo, Bar} = new Friends()

const f = new Foo()
const b = new Bar()

f.fooMethod() // logs "456"
b.barMethod() // logs "789"

💻 Use Cases

Allows having a "private" key to use on multiple classes, but each class could have a different type of value.

[Andarist]

I assume you might be looking for some improvements for .js files where some props can be inferred from their assignments in constructors etc.

This repro shows multiple problems (I found 2 issues in emitted .d.ts 😅 ). But even this doesn't behave correctly:

// @filename: index..ts

class Friends {
  #priv;

  Foo = class Foo extends Friends {
    constructor() {
      super();
      this.#priv = 456; // missing error
      this.nonDeclared = "foo"; // errors
    }
  };
}

[Andarist]

Actually, this works as expected. At runtime this.#priv can be accessed by subclasses when they are defined within their superclass:

class Test1 {
  #priv = 10;

  Foo = class Foo extends Test1 {
    constructor() {
      super();
      console.log(this.#priv);
    }
  };
}

const t1 = new Test1();
new t1.Foo(); // logs: 10

So as long as you don't redefine them in those subclasses (to "shadow" those private props) their type will stay the same as the one defined at the declaration site (that's an implicit any in your example).

[Andarist]

That said, unfortunately redefining them in those nested subclasses won't be too portable. See #60885 and the reasoning outlined in the PR's description there.