Gleam module visibility: Transitioning from naming conventions to enforced encapsulation

Module-Level Access Control

Gleam currently implements a public-by-default visibility model for functions and types declared within a module. To maintain a clean public API surface, developers typically rely on naming conventions or the segregation of internal logic into separate modules.

Encapsulation Constraints

Because the language lacks a built-in private or internal keyword, there is no compiler-enforced mechanism to restrict a function's visibility to its own module while the module remains exported. This relies on the developer to manually manage the public surface area without the aid of granular visibility modifiers like package-private access.

Given the current module system architecture in stable releases, what are the recommended strategies for ensuring strict encapsulation? Is there a planned mechanism for compiler-enforced private visibility within a public module?