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**: ``` 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** ``` ts class C { internal x: number; } ``` **source.ts** ``` ts /// <reference path="declaration.d.ts" /> let c = new C(); c.x = 1;

Posted by rbuckton on Oct 12, 2015, 6:27 PM

Tags

• github (Other)

Related issues

• struct's lifetime requirements can be bypassed via covariant field assignment
• Proposal to Reorganize the Moderation Team and Review Moderation Policies
• Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
• proposal: container/...: generic collection types
• Better Custom Endpoint BYOK
• A concrete policy for backward compatibility until Godot 5.0