Modules and visibility

Platform spec node

Modules and visibility

Back to Program structure ◎ Open in platform map

Spec standingStandard

Owner

Piotr Mikstacki pmikstacki@cybernomad.it

Submitter

Piotr Mikstacki pmikstacki@cybernomad.it

Current document

ADRs

No architecture decision records under adr/ for this feature yet. Standard features must publish at least one ADR or keep a ## Decisions summary on the hub.

Articles

• Code style and naming Language-level naming and style conventions that affect readability and tooling consistency. article Proposed
• extend type Type extension syntax replacing impl blocks; public members only, full type scope access. article Standard Reviewed Wed May 20
• Modules and visibility File layout, `public`/`internal` boundaries, and how packages compose. The driver and package manager use the same module graph the typechecker sees. article Standard Reviewed Thu May 21
• Name resolution Scopes, imports, and shadowing tie syntax to symbols. Diagnostics for unresolved names must cite these rules verbatim. article Standard Reviewed Thu May 21

History

0 revisions (git unavailable at build; counts may be empty)

Open full history on GitHub

No commits recorded for this path.

Completeness

OKarea · 2 SpecSection(s) · 0 H2 heading(s)

Section id	Required	Found
scope	yes	yes
features	yes	yes

Full tree: run pnpm verify:platform-spec-layout (writes src/generated/platform-spec-layout-report.json).

Related spec docs

• Area
  Program structure

  Parent area

• Domain
  Language meta

  Parent domain hub

• Domain
  Platform specification

  Cross-cutting index

• Domain
  Execution documentation

  Non-normative legacy execution bridge

Normative specification

Scope

Defines the module graph, file-scoped modules, and pub visibility rules. Name binding is in Name resolution.

Module forms

Form	Rule
Path mod	mod a.b; declares the file’s module path; must be the first top-level item when used (E1505, E1506, E1507)
Inline mod	mod name { items } nests a submodule in the current file
File path	Without file-scoped mod, module identity must derive from file path relative to project source root

Visibility

• Items default to private to their module.
• pub on an item must export it to importers of the containing module.
• pub use path re-exports symbols; re-exported names must refer to accessible items.
• Importing a private item must error (E1501, E1107).

Static rules

• Duplicate module declarations in one file must error.
• Nested mod declarations inside a file-scoped module file must error (E1507).
• Package boundaries must align with project manifests; cross-package visibility follows the same pub rules within each compilation.

Dynamic semantics

Modules exist at compile time; runtime has no separate module loader beyond linked assemblies/packages produced by the toolchain.

Diagnostics

Visibility band E1501–E1507; unused import W1503. Registry: Diagnostic code registry.

Conformance

L1 implementations must match reference layout tests for file-scoped modules and pub boundaries.

Decisions

• D-LM-MOD-001 — File-scoped precedence: Explicit mod path; wins over path-derived module identity when present.
• D-LM-MOD-002 — No internal keyword: v0.1 uses private-by-default plus pub; assembly-internal friends are deferred.
• D-LM-MOD-003 — Package graph is external: Cross-package edges come from manifests; this chapter defines symbol visibility only.
• D-LM-MOD-004 — pub use re-export: Re-exports must preserve the underlying symbol’s accessibility rules.

Platform view

File layout, public/internal boundaries, and how packages compose. The driver and package manager use the same module graph the typechecker sees.