Programming Language

Nocter

A self-contained systems language built around simplicity, encapsulation, and foolproof design.

/development/reviews/v0.33.0-phases-1-3.md

v0.33.0 Phases 1–3 Structural-tuple Implementation Review

Status: complete with no open finding (2026-09-04). Structural tuples now cross the complete frontend, checked-program, executable, runtime, machine, standard-library, and editor pipeline. This review does not assign a release version to an archive, qualify an installed v0.33.0 home, or make a publication claim; those remain Phase 4 work.

Authority Trace

The review followed one tuple from authored source to emitted machine operations and back to editor presentation:

  • nocter-syntax owns tuple delimiters, commas, positional member tokens, recursive local-binding patterns, and the closed set of postfix suffix shapes;
  • TypeStore owns ordered structural type identity through TupleElements, whose constructor enforces the language's minimum arity before a tuple type can be interned;
  • checking owns expected-type propagation, construction operations, positional places, recursive binding operations, move and copy selection, loans, provenance, cleanup timing, and destruction subsets;
  • MIR consumes those checked decisions and represents tuple aggregate construction, positional projection, and structural destruction without reopening type or ownership selection;
  • the runtime contract closes tuple element types for the target boundary and rejects an invalid arity before a runtime environment can be published;
  • MachineLayoutStore computes each concrete tuple's size, alignment, and element offsets once; aggregate lowering, address projection, generated destruction, and ABI classification consume that stored layout;
  • source indexing records an exact tuple-projection occurrence, while hover, highlighting, and navigation consume the checked place and type instead of reconstructing tuple semantics from text;
  • recovery completion receives an owned TypeProjection, so it can present tuple elements without retaining a raw type identity whose authority may belong to another recovery transaction.

No layer models a tuple as a nominal declaration, creates synthetic fields, reuses PackEntry, or derives layout from rendered names.

Findings Closed During Implementation

Four cross-cutting defects were exposed and fixed at their shared boundaries:

  1. 1. Chained projection initially depended on a manually maintained list of postfix syntax nodes. PostfixSuffixKind now closes that syntax classification, and semantic consumers must handle every suffix exhaustively.
  2. Recovery completion initially retained a raw TypeId from a temporary checking authority. Tuple completion now owns the transitive TypeProjection needed for presentation, preserving type-store isolation.
  3. Interactive source selection used a permissive entity filter and omitted the new positional projection occurrence. It is now an exhaustive match over SemanticEntity, with a regression test requiring the exact .0 range, checked hover, readonly classification, and no invented definition target.
  4. The semantic tuple constructor enforced minimum arity, but the exported runtime shape did not. Runtime-environment finalization now rejects tuple shapes outside the language contract, so a caller cannot create an invalid backend input by using the public builder incorrectly.

Discarded and partially moved elements use the same checked cleanup authority as named bindings. CleanupTiming::DuringBinding expresses immediate discard cleanup; MIR does not synthesize a second ownership rule. Reverse destruction order comes from one structural destruction plan and is preserved through machine lowering.

Practical Surface

str.split_once(separator) returns (&str, &str)? from self and is tested for a present separator, an absent separator, and an empty separator. examples/tuples.nct exercises tuple return values, numeric projection, mutation through a projected place, local destructuring, discard patterns, rvalue projection, and owned destruction. These are ordinary public sources discovered by the existing formatter, native-session, command, and documentation catalogs; no tuple-specific fixture registry was added.

Verification

The implementation passes:

  • cargo test --locked --workspace --all-targets; every enabled test passes and the one public-HTTPS acquisition test remains intentionally ignored;
  • cargo clippy --locked --workspace --all-targets --no-default-features -- -D warnings;
  • cargo check --locked --workspace --no-default-features;
  • cargo fmt --all -- --check and git diff --check;
  • deterministic 457-page documentation generation and catalog-drift rejection;
  • shell syntax checks for both packaging scripts and JavaScript syntax checks for documentation, manifest, and installed-LSP tooling;
  • focused native execution for the standard tuple contract, structural ownership and destruction, runtime shape validation, machine layout and ABI, semantic projection, completion, formatting, and LSP protocol behavior.

Phase 4 must still assign the v0.33.0 candidate identity before deterministic archive generation and fresh installed-home qualification can be meaningful. No implementation or responsibility-boundary finding blocks that work.