Skip to main content
Language v0.2.0 · Preview

Explicit N/M module visibility

Negotiate public/private workspace exports while keeping private declarations local and stable 0.1 declarations legacy-public.

Explicit N/M 0.2 module visibility

NM-RFC-0001 gives workspace modules an explicit export boundary without changing stable 0.1 source. Public and private declarations are accepted only after deliberate feature negotiation.

NM-RFC-0001experimental0.2.0-tooling-experimental
3
supported declaration kinds: circuit, observable, const

Local availability

A private circuit, observable, or constant remains available inside its declaring module. Local document symbols also keep it visible to the author.

Workspace export filtering

Imported completion, workspace symbols, definition, signature help, references, prepare-rename, and rename expose public and legacy-unqualified declarations but exclude private declarations.

Stable-default compatibility

Unqualified 0.1 declarations remain legacy-public. Without the experimental flag, public/private syntax is rejected with a stable diagnostic instead of changing project meaning silently.

Module and consumer

module phase_helpers; private const HALF = PI / 2; private circuit prepare_phase(data: QReg<1>) {  Ry(data[0], HALF);} public circuit prepare_plus(data: QReg<1>) {  H(data[0]);} // consumer.nmuse workspace.phase_helpers;// prepare_plus(q) is exported; prepare_phase(q) is not.

Explicit negotiation

parseNMCode(source, { experimental: { moduleVisibility: true } })nm check main.nm --experimental-module-visibilityinitializationOptions.nm.experimental.moduleVisibility = truenm.experimental.moduleVisibility = true

Contract diagnostics

NM-PARSE-051NM-PARSE-052

Visibility is a language namespace boundary, not access control. It does not protect source from readers and does not define package publication, re-exports, friend modules, or source-version negotiation.