An `internal` property modifier as an alternative to `protected`

[denis-migdal]

🔍 Search Terms

• protected alternative
• internal

Related issues:

• Explain why private and protected members in a class affect their compatibility #18499
• Proposal: The internal modifier for classes #5228

✅ 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

Currently, protected causes several issues:

• you can't use duck typing when a class have a protected property. You can't implement it, you are required to extend it.
• protected (and private) properties often disappear when manipulating types.

I'd like an internal modifier that would behave similarly to readonly.
It would declare the property is part of the public interface, but you can't access it outside of its methods (a.k.a. functions where the type of this is the type of the instance).

📃 Motivating Example

Such feature could be used for several usages.

Having friends

Currently, TS has no friend, even though this seems to be a frequently requested feature:

• Proposal: Friend Declarations for classes #7692
• Add a visibility mechanism similar to friend or InternalsVisibleTo #35554

An internal modifier would be a cleaner way to have friends:

1. you declare a function/class with some internal properties.
2. you can safely cast such object by removing the internal modifier with some type manipulations (e.g. with -internal).

You can then select exactly which properties are accessibles from friends (which helps respecting encapsulation).

Implementing classes with internal properties

Sometimes we want to implement a class instead of extending it. However, this is not possible when using protected properties:

• Enables implements on abstract classes with protected members (usefull for generic mixins) #61161

Defining interfaces with internal properties

We could also define interfaces with internal properties, e.g. hooks that could be overridden when extending a class implementing the interface, without even requiring to know the class true concrete type.

Manipulating internal properties

This would also enable more complex type manipulations, e.g.:

• [Feature Request] fieldof similar to keyof but include private and protected field #46802

💻 Use Cases

Currently, there are several workarounds.

Cast

const internal = target as FooInternals;

Can be dangerous. A "type map" can be used to make the cast slightly more secure, but this is still unsafe.

Public properties

Making the properties public solves most of the issue, however, this makes properties publicly accessible, loosing some protections.

Symbols

We can hide the internal type behind a symbol.

class Foo {
      [SYMBOL] = this as InternalFoo;
      // or
       [SYMBOL] = { ... }
}

However, this is not ideal when manipulating classes in mixins (attributes aren't accessible from the prototype, and we can't really manipulate the constructor).

Hooks in the constructor

In some cases, you can give hooks in the base class constructor instead of overriding protected methods.

class Foo {
      [HOOKS]: XX; // not in the FooClass interface.

      constructor(hooks) {
             this[HOOKS] = hooks;
      }
}

But same as previously, this is not ideal when manipulating classes in mixins.

Static properties

Another way is to declare static instance methods that can be redefined:

class X {
      static onChange = () => {};
      foo() {
            this.constructor.onChange.call(this); // not type safe.
      }
}

However this is not truly type safe:

• T.constructor should be of type T #3841

Alternative suggestion :

This issue could also be solved by specifying a public and an internal type for the same property:

• [feature] class properties that are "readonly in public, writable in private" or other permutations #37487
• Distinct type specification for public field members #54829

The usage could then be something like foo: $PUB_TYPE @internally=$INTERNAL_TYPE, e.g.:

• foo: never @internally=number.
• foo: readonly number @internally=number.
• foo: X @internally=XInternals.

However this would require bigger changes to TS.

[MartinJohns]

Duplicate of #5228.

[im-alok74]

Martin Johns (@MartinJohns) Thanks for the pointer to #5228 — I saw that thread too, though it's been open since 2017 without resolution, and this proposal (readonly-like internal modifier, distinct from protected's inheritance-based visibility) is a bit more specific in its semantics.

I'd be interested in implementing this if the team would consider it. Before I put together a PR, I wanted to check:

1. Is there any appetite from the TypeScript team for a new access modifier here, given the design goals around not adding runtime-affecting syntax?
2. Would you prefer discussion consolidated on Proposal: The internal modifier for classes #5228 instead, or is this issue's narrower proposal (property-only, duck-typing-compatible) worth tracking separately?
3. Is there a design doc or precedent I should follow for how new modifiers get threaded through the parser/checker/emitter (e.g. how override was added)?

Happy to start on a prototype either way, but wanted to avoid spending time on an implementation that's unlikely to be accepted without a design decision first.

[denis-migdal]

Duplicate of #5228.

As far as I understand, not really.

They want it to be a "package" visibility, treating it as public in its declaration file.
Maybe the name internal I choose is a little ambiguous, and a better name could be found.

[MartinJohns]

My mistake

It would declare the property is part of the public interface, but you can't access it outside of its methods

This is actually a duplicate of #37487.

[denis-migdal]

My mistake

It would declare the property is part of the public interface, but you can't access it outside of its methods

This is actually a duplicate of #37487.

No, this suggestion is for a property readable in public, and writable inside the methods.
A variant of this could solve my issue by declaring a public property type as never, and the "internal" type as we wish to.

In my suggestion, the property can't be used by the outside, it exists but you can't read, write, or call it.

You can see my "internal" properties as an "internal interface". Outside code is forbidden to depend on it, but the interface must be here to be able to call some internal helper functions.

Like we could do with protected properties, but with more flexibility and type safety.