Inability to use typeof on an ES private property

[rraziel]

Bug Report

🔎 Search Terms

• typeof
• private

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about private and typeof

⏯ Playground Link

Playground link with relevant code

💻 Code

class Example {
  #privateProp = 'hello';

  constructor() {
    const p: typeof this.#privateProp = 'world';
    const p2: Example['#privateProp'] = 'world';
  }
}

The example is kept short for reproduction, but in practice this is more for cases where you would want to use keyof this.#someProperty and similar constructs (since here the type could just be inferred).

🙁 Actual behavior

Specifying a type using const name: typeof this.#anESprivateProperty is not possible.

For p, the error is that an identifier is expected (because it's a PrivateIdentifier and not an Identifier from the compiler's pov?).

For p2, the error is that the property does not exist on the type, which is logical when done from "outside" the class where the property should not be visible.

🙂 Expected behavior

Having the ability to use typeof on an ES private property from "inside" the class itself where that property is visible, e.g. like in the example code above.

[rraziel]

I wouldn't mind giving it a shot with a PR, but just to see if I'm at least on the right track before I start going down that path:

• NodeFactory.createTypeQueryNode (when doing typeof this.#abc) needs an entity name
• NodeFactory.createQualifiedName can't be used for that as the second arg must be an Identifier, and here it's a PrivateIdentifier

Would this be the correct way to get the feature to work?

[a-tarasyuk]

@RyanCavanaugh Do we need to support this syntax?

const p2: Example['#privateProp'] = 'world';

TypeScript/tests/cases/conformance/classes/members/privateNames/privateNamesAndIndexedAccess.ts

Lines 12 to 13 in 3206df8

	// will never use this syntax, already taken:
	const badAlways: C["#bar"] = 3; // Error

class C {
    #a = 1;      // number
    ["#a"] = ""; // string

    constructor() {
        const a: C["#a"] = 1; // Should the checker use a number or a string?
    }
}

#a and ['#a'] are two different props - Playground

If we allow C["#a"], the next property should get type number. :)

TypeScript/tests/cases/conformance/classes/members/privateNames/privateNameAndIndexSignature.ts

Line 10 in eb3e7bd

this["#foo"] = 3; // Okay (type has index signature and "#foo" does not collide with private identifier #foo)

[fatcerberus]

obj['#privateProp'] accesses a different property at runtime than obj.#privateProp; the syntax in question refers to the former. That's what's meant by "already taken".

[dnalborczyk]

@RyanCavanaugh Do we need to support this syntax?

const p2: Example['#privateProp'] = 'world';

already in use with public properties.

class Example {
  #privateProp = 'hello';

  ['#publicProp']: number
}

type Prop = Example['#publicProp']

https://www.typescriptlang.org/play?#code/MYGwhgzhAECiAeYC2AHEBTaBvAsAKGmgGIUAnASwDcwAXdABVIHsVoBeaAcgAt0QQmnANz58hANqcSAVwBGIcsEYtOAXQBc0AHbSks9KXwBfUXhoBPFJmWsOCZGnSSZ8xTbVA

[fatcerberus]

@a-tarasyuk Since C["#a"] in your example already refers to the public property ("number is not assignable to string"); changing it to refer to the private property would be a pretty big breaking change.

[RyanCavanaugh]

For now I would not support indexed access lookup (const p: C["#p"] or variants thereof); it's very messy. Accessing the type of a private property from outside the class is a huge code smell since it breaks under declaration emit, and should really be avoided.

typeof this.#p (from inside the class) should be the only way to get at it.

[dnalborczyk]

typeof this.#p (from inside the class) should be the only way to get at it.

that would make sense and that's pretty much the same how symbols as properties are being handled.