Repository: TypeScript
Issue: Feature Request: access inherited protected member in subclasses branched from a base class where the protected member is defined in the base class
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Please read the FAQ first, especially the "Common Feature Requests" section.

-->

## Search Terms

- typescript protected class branch
- typescript access protected in sibling

## Suggestion

Allow subclasses to access inherited protected members across instances of the subclasses.

## Use Cases

There are use cases when we'd like subclass branches that inherit a protected member to be able to access the inherited protected member across instances of the branched subclasses.

There are also use cases where subclasses cause invariants by narrowing the type of an inherited member, which we should be able to guard against at compile time.

## Examples

This [PlayGround example](http://www.typescriptlang.org/play/#src=let%20counter%20%3D%200%0D%0A%0D%0Aclass%20Base%20%7B%20%0D%0A%20%20%20%20protected%20foo%20%3D%20%2B%2Bcounter%0D%0A%7D%0D%0A%0D%0Aclass%20A%20extends%20Base%20%7B%0D%0A%20%20%20%20getOtherFoo(other%3A%20Base)%20%7B%0D%0A%20%20%20%20%20%20%20%20return%20other.foo%0D%0A%20%20%20%20%7D%0D%0A%7D%0D%0A%0D%0Aclass%20B%20extends%20Base%20%7B%0D%0A%7D%0D%0A%0D%0Aconst%20a%20%3D%20new%20A%0D%0Aconst%20b%20%3D%20new%20B%0D%0A%0D%0Aconsole.log(a.getOtherFoo(b))%20%2F%2F%202%0D%0A%0D%0Aclass%20MyClass%20%7B%0D%0A%20%20%20%20protected%20protectedProperty%3A%20number%20%3D%201%0D%0A%7D%0D%0A%0D%0Aclass%20MySubClass%20extends%20MyClass%20%7B%0D%0A%20%20%20%20protected%20protectedProperty%3A%20number%20%3D%202%0D%0A%20%20%20%20static%20compare(a%3A%20MyClass%2C%20b%3A%20MySubClass)%3A%20number%20%7B%0D%0A%20%20%20%20%20%20%20%20return%20a.protectedProperty%20-%20b.protectedProperty%3B%0D%0A%20%20%20%20%7D%0D%0A%7D%0D%0A%0D%0Aconst%20m1%20%3D%20new%20MyClass%0D%0Aconst%20m2%20%3D%20new%20MySubClass%0D%0A%0D%0Aconsole.log(MySubClass.compare(m1%2C%20m2))%20%2F%2F%20-1) doesn't work, to illustrate the current limitation.

I have a use case, where I have a `TreeNode` sort of class with protected properties, then I have subclasses of the TreeNode, one called `Mesh`, and the other called `Scene`, where the Scene needs to traverse the tree to run logic using the protected members (thus reading the protected member of all instances of `Mesh`), but TypeScript won't allow it.

The code that is `Scene`-specific lives inside the `Scene` class (because that makes sense).

To make it work, I'd have to move that code into the common base class `TreeNode`, but then it will be messy and un-organized.

FWIW, I have the same problem in my runtime JS class implementation, [lowclass](https://github.com/trusktr/lowclass), which I'm now thinking about solving with an option.

In general, I think that well-designed classes will benefit from this feature, and that poor coding practices will lead to issues with this (which is why the compiler should catch the problems in those cases). (f.e.  if base class specifies a protected member of type `number | string`, and a sibling subclass changes it to `number`, then the compiler can obviously catch a problem when another sibling subclass wants to read from the other one and hasn't narrowed the type to `number` as well.)

## implementation ideas

A subset of the following ideas might do the trick:

- a compiler option to allow or disallow this feature
- We can detect invariants at compile time. From [this post](https://stackoverflow.com/questions/1904782/whats-the-real-reason-for-preventing-protected-member-access-through-a-base-sib),
  > Other sibling classes might add invariants that your class doesn't know about
  
  In the above example, if the types agree in the subclasses, we can let it work, and throw a runtime error only when there is a type mismatch. But suppose in my above example that `Scene` and `Mesh` don't modify the inherited protected type, and only read it or set it. The compiler can easily ensure that things are okay.
- disallow subclasses from modifying types of inherited members
  - perhaps a compiler option for this
  - this can prevent subclasses of subclasses of subclasses from being so far removed (not resembling their base class at all), by forcing subclasses to add new features on new properties instead of existing ones
- Follow the same rules as public, which is not guarded against this. An invariant problem can happen across siblings inheriting and modifying the member from the base class, yet the compiler will not stop it.
 - another compiler option

Mainly, my reasoning above is that there is a way to make this work with some semantics and/or options, and it is okay if those are specific to TypeScript. We won't invent new wheels, but we can improve existing wheels instead of copying them.

## Checklist

My suggestion meets these guidelines:

* [ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code _**not sure**_
* [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, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).

**Related Issues:** 

- https://github.com/Microsoft/TypeScript/issues/1
- https://github.com/Microsoft/TypeScript/issues/8512
- https://github.com/Microsoft/TypeScript/issues/10637
- https://github.com/Microsoft/TypeScript/issues/11278
- https://github.com/Microsoft/TypeScript/issues/11832
- https://github.com/Microsoft/TypeScript/issues/22900