Gleam 1.0 module privacy: choosing the export boundary when pub is the only modifier

Gleam 1.x treats every top-level function as private unless it carries the pub keyword. Code written against earlier releases that relied on implicit cross-module access therefore sits on a compatibility boundary: source that compiled before now needs an explicit export decision for each function another module calls.

That decision is straightforward for a library's intended API. It is less clear for helpers shared between modules of one package but not meant for downstream users, and for functions reached only from a test module. Gleam's visibility model offers pub as the export modifier, so marking such a helper public also exposes it to every dependent package and to Erlang or Elixir callers of the compiled output.

Verification is compile-time: a call to a non-public function is rejected, and the generated Erlang export directives are expected to follow the same boundary. The open question is how teams should draw the line.

• When a helper is used by two modules in the same package, is pub the intended answer, or should the code be restructured?
• How should test-only access be handled without widening the published API?
• Does the Erlang interop boundary change the calculus for packages consumed from other BEAM languages?