v0.33.0 Phase 0 Review

Result: complete with no open finding. This review evaluates the structural-tuple contract and the current compiler boundaries before implementation begins.

Existing Boundaries Audited

The audit followed type syntax, grouped expressions, local bindings, semantic type interning, checked aggregates and places, loan projections, move eligibility, MIR aggregates and destruction, closed runtime types, machine layout, machine aggregate operations, semantic presentation, source indexing, formatting, and editor queries.

The current compiler has no tuple identity. Parenthesized type and expression parsers currently own grouping, closure lookahead, and callable syntax. Nominal aggregates carry declaration-owned fields; the internal PackEntry carries keyed expansion semantics. Neither is a correct tuple authority.

Runtime nominal aggregates intentionally separate a closed Aggregate shape from a specialized field-representation table. A tuple can remain structural by carrying concrete ordered element types in its closed runtime kind and by receiving a positional MachineLayoutStore entry. Machine aggregate and ABI machinery already operates on frozen size, alignment, and offsets, so native instruction selection does not need to understand source tuple syntax.

Findings Closed by the Design

Synthetic nominal types would create false ownership

Encoding each tuple as an anonymous struct would require fake declaration and field identities. Visibility, member lookup, navigation, interface selection, destruction, and display would then depend on compiler-generated nominal artifacts. The adopted model adds a structural tuple type and positional projections instead.

PackEntry reuse would merge unrelated semantics

PackEntry is a keyed compiler-owned shape used by argument-pack expansion and deliberately has no source presentation. A tuple is ordered, user-visible, independently borrowable data. Both remain separate types and lower through their own checked contracts.

Parser-only destructuring would repeat semantic work

A syntax tree alone cannot decide move versus copy, loan disjointness, discard destruction, or the type of a nested element. Checking therefore produces a recursive binding plan. MIR consumes the plan and cannot reinterpret the source pattern.

Reusing nominal fields would make partial moves unsound or order-dependent

Tuple positions are first-class checked and MIR projections. Loan paths use positions, allowing different elements to remain disjoint. Move eligibility is generalized around value-preserving projections rather than extended by another scattered special case.

Tool-specific tuple reconstruction would create a second language

Canonical tuple spelling comes only from semantic TypeStore identity. Source ranges and numeric projection occurrences come from parser and checked evidence. Editor features cannot scan text to guess tuple structure or synthesize member definitions.

Layout could be recomputed after semantic lowering

The executable contract retains concrete ordered element types. MachineLayoutStore computes the ordered product layout once. MIR address lowering, calling convention selection, and native instruction emission consume that frozen result and cannot derive it independently.

Feasibility

The grammar has unambiguous decision points:

• after the first parenthesized type or expression, a comma selects a tuple;
• closure syntax remains selected by the token following its complete parameter parentheses;
• callable types retain their leading func spelling;
• a decimal token following member . selects a tuple projection, while an identifier continues to select a named member.

The semantic store already interns recursive structural type kinds and precomputes type properties. The runtime type table already validates closed referenced type identities. Its private validation match currently handles only unary and keyed-binary structural shapes; Phase 2 must generalize that validation to visit every tuple element rather than bypassing it. MachineLayoutStore already owns aggregate offsets, and the native backend consumes generic aggregate reads and writes. These are extension points, not alternate tuple authorities.

The required change is compiler-wide but does not require a compatibility mode, source-index semantic input, synthetic declarations, a new backend ABI authority, or a tuple-specific LSP parser.

Boundary Review

• Public behavior has one normative owner in the tuple specification chapter.
• Every tuple fact has one authority and flows toward later representations.
• Named records remain nominal; internal pack entries remain keyed; tuples remain positional.
• Checking exports explicit tuple places and binding plans without leaking checker state.
• Runtime and machine layers cannot consult syntax or source indexing.
• Editor presentation consumes semantic identity and cannot affect checking.
• No old syntax or representation requires compatibility support because tuples are new.

Verification

• node docs/build-docs.js generated the complete public site and validated documentation links, catalogs, diagnostic codes, and crate documentation.
• cargo fmt --manifest-path development/compiler/Cargo.toml --all --check passed.
• cargo test --manifest-path development/compiler/Cargo.toml --workspace --locked passed across the complete current compiler baseline.
• git diff --check passed.

Phase 1 may begin without an unresolved language or representation decision.