nonexported

Nonexported is a term used in modular programming to describe identifiers (such as functions, types, constants, or variables) that are defined within a module or package but are not exposed to code outside that module. Non-exported identifiers are considered internal implementation details and are not part of the module’s public API. The distinction between exported and non-exported members helps enforce encapsulation, allowing the module to evolve its internal structure without breaking users who rely on the public interface.

Go uses a simple convention: identifiers that begin with a lowercase letter are unexported, while those that begin with an uppercase letter are exported. In Rust, items are private by default; to be accessible from other modules or crates, an item must be declared pub. Non-pub items are non-exported. JavaScript and TypeScript modules export bindings with the export keyword; bindings not exported remain internal to the module and cannot be imported by consumers. Python does not enforce private members at the language level; leading underscores and the __all__ list control what a module presents as its public API, though access is still possible.

Use of non-exported members supports interface stability, security, and maintainability by hiding implementation details such as helper functions, internal data structures, and response formats. When designing a module, developers typically expose a stable public API and keep internal helpers private. Tests often focus on the public API, though testing non-exported code may be necessary in internal test suites.

Changing a non-exported member to exported can be a backward-incompatible change if it reveals new behavior; similarly, introducing non-exported members may require careful refactoring. Documentation often notes the intended public surface while suppressing internal items.