Proposal: The internal modifier for classes

The internal modifier

Often there is a need to share information on types within a program or package that should not be accessed from outside of the program or package. While the public accessibility modifier allows types to share information, is insufficient for this case as consumers of the package have access to the information. While the private accessibility modifier prevents consumers of the package from accessing information from the type, it is insufficient for this case as types within the package also cannot access the information. To satisfy this case, we propose the addition of the internal modifier to class members.

Goals

This proposal aims to describe the static semantics of the internal modifier as it applies to members of a class (methods, accessors, and properties).

Non-goals

This proposal does not cover any other use of the internal modifier on other declarations.

Static Semantics

Visibility

Within a non-declaration file, a class member marked internal is treated as if it had public visibility for any property access:

source.ts:

class C {
    internal x: number;
}

let c = new C();
c.x = 1; // ok

When consuming a class from a declaration file, a class member marked internal is treated as if it had private visibility for any property access:

declaration.d.ts

class C {
    internal x: number;
}

source.ts

/// <reference path="declaration.d.ts" />
let c = new C();
c.x = 1; // error

Assignability

When checking assignability of types within a non-declaration file, a class member marked internal is treated as if it had public visibility:

source.ts:

class C {
    internal x: number;
}

interface X {
    x: number;
}

let x: X = new C(); // ok

If one of the types is imported or referenced from a declaration file, but the other is defined inside of a non-declaration file, a class member marked internal is treated as if it had private visibility:

declaration.d.ts

class C {
    internal x: number;
}

source.ts

/// <reference path="declaration.d.ts" />
interface X {
}

let x: X = new C(); // error

It is important to allow assignability between super- and subclasses from a declaration file with overridden members marked internal. When both types are imported or referenced from a declaration file, a class member marked internal is treated as if it had protected visibility:

declaration.d.ts

class C {
    internal x(): void;
}

class D extends C {
    internal x(): void;
}

source.ts

/// <reference path="declaration.d.ts" />
let c: C = new D(); // ok

However, this does not carry over to subclasses that are defined in a non-declaration file:

declaration.d.ts

class C {
    internal x(): void;
}

source.ts

/// <reference path="declaration.d.ts" />
class D extends C {
    internal x(): void; // error
}

[EisenbergEffect]

@rbuckton Is there any status on this? It’s been 2.5 years since this was proposed. I’m working on Aurelia vNext right now, completely written in TS. We could really make use of this feature…

[matthewmueller]

I’d like to see this too, but have you guys considered the way Golang handles this? I find their approach quite elegant.

They let you have a directory called /internal, which only allows access to internal modules in the folder that contains that internal folder (and access from within that internal folder)

Graphically it looks like this:

/project
  /internal
    /component
      component.go // internal
  /api
    api.go // access to internal component
  main.go // access to internal component

/another-project
  main.go // no access to project's internal component