Inconsistency in Generic Inference for Private Properties about typescript HOT 4 OPEN

such as the cases of inheritance

Inherited classes should not access private members. Removing the type is/was necessary for compatibility/implementation-hiding reasons: #38953 (comment)

This is somewhat a duplicate of #51489.

from typescript.

@MartinJohns

Alright, after reviewing the information you provided, I understand the complexity of this issue.

There are indeed several ways to address this problem, such as using protected or using a symbol to retain the type.

const xxx: unique symbol = Symbol()
class MyClass1<A> {
  declare [xxx]: A
  private a: A;
  constructor(a: A) {
    this.a = a
  }
}

However, one concern is that I test my code in ProjectA, everything works fine, but only after compiling, publishing, and then importing into ProjectB do I encounter the issue. This situation is troublesome because I have to go back and modify ProjectA.

Ideally, if such coding practices are not allowed, I would prefer to be notified of errors while writing ProjectA.

I expect consistency in behavior before and after code compilation.

from typescript.

So even though the property is private, it has observable structural implications that are lost in the generated typings.

Would the ideal be that private properties be hidden from inference machinery so that code like type X2 = MyClass2Sub<number> extends MyClass2<infer x> ? x : never would always yield never?

from typescript.

So even though the property is private, it has observable structural implications that are lost in the generated typings.

Would the ideal be that private properties be hidden from inference machinery so that code like type X2 = MyClass2Sub<number> extends MyClass2<infer x> ? x : never would always yield never?

Yes, I'd rather catch issues while writing code than discover them after publishing a package.

from typescript.