v0.18.0 Phase 2 Final Review

Status: complete on 2026-08-26. This review covers instance-owned interface implementation, associated-binding blocks, nominal impl requirements, and callable type requirements. It applies the repository boundary rule that each responsibility may depend on another responsibility's published contract but not on its implementation details.

Reviewed Boundaries

Findings And Remediation

1. Interface applications and associated bindings had separate semantic records

The initial migration lowered T impl Iterator { .Item = U } into adjacent interface and associated type requirements. Presentation then regrouped those records, while proof depended on their relationship. That made source order an implicit contract and gave presentation a second assembly rule.

Resolution: one RequirementKind::Interface now owns the subject, exact interface application, and all associated bindings. Binding, validation, proof, opaque witnesses, generic iteration, and presentation consume that aggregate directly. No downstream layer reconstructs a predicate from adjacent records. Each source binding begins with . so syntax can commit to a binding block before reading its name or =, and the spelling visibly denotes a member relative to the immediately preceding interface application.

2. Callable types shared an abstraction with nominal interface evidence

The former capability model represented nominal interface satisfaction and callable shape in one union. This obscured the fact that func(I): O is a type contract with a concrete static witness, not an interface implemented through nominal conformance.

Resolution: declaration and checked requirements now distinguish Interface from Callable. where F: Callback normalizes the right-hand type and accepts only a callable type or alias; where F impl func(...) is rejected by syntax, and a non-callable annotation receives authored diagnostic E0314. Callable values retain direct specialization and introduce no erased runtime representation or interface dispatch.

3. Accepted declaration state was optional data

DeclarationProgram previously carried optional admission and relied on a panic when a consumer converted it into checking input. The control flow validated the program, but the type did not express that precondition.

Resolution: DeclarationProgram is the structurally valid base graph and AcceptedDeclarationProgram is the only checking input. Successful validation constructs the accepted type; rejected recovery retains the base graph plus explicit recovery capabilities. There is no optional admission field, unchecked conversion, or panic-based production transition.

4. Standalone conformance ownership duplicated instance behavior ownership

The old declaration family owned generic parameters, target patterns, requirements, and method matching separately from instance. Preserving it behind new spelling would retain two behavioral attachment models and a contract-joining path.

Resolution: InterfaceImplementation stores its owner InstanceId, exact interface application, and associated bindings. Generic parameters, target, requirements, and inherent methods come from that instance. The old syntax parser, declaration identity, lowering module, checking module, and analysis action were removed rather than wrapped.

5. Implementation fragments needed an explicit source authority

Public index.nct contracts and private implementation-source method bodies can occupy separate exact-header instance fragments. Selecting a writable fragment from paths or syntax shape in the editor would repeat source-topology policy.

Resolution: declaration lowering joins exact-header fragments through reciprocal source visibility, and SourceIndex records their semantic roles. Interface facts are allowed only in the public contract source. The missing-method action consumes those roles to select an editable method owner; it does not infer module structure or repeat implementation applicability.

6. Historical terminology survived across internal contracts

The migration initially retained generic Capability and Conformance names in type lowering and checking. Those names hid the new distinction and made future accidental reunification plausible.

Resolution: obsolete capability records, standalone associated-binding predicates, conformance IDs, parsers, modules, diagnostics, and source files were removed. Interface application is named explicitly at each boundary. Remaining uses of “conformance” describe the compiler's grammar-conformance test suite, not a language declaration.

Authority And Flow Audit

The completed nominal flow is:

instance syntax
  -> resolved InstanceDeclaration
  -> owned InterfaceImplementation
  -> accepted declaration graph
  -> checked interface-method selection
  -> concrete dispatch and semantic presentation

The completed generic requirement flow is:

InterfacePredicate + AssociatedBindings
  -> aggregate RequirementKind::Interface
  -> aggregate BoundRequirementKind::Interface
  -> CheckedPredicate::Interface
  -> lexical or concrete proof

Syntax owns spelling and ranges. Declaration lowering owns name binding and source-fragment joining. Declarations own immutable contracts and admission. Checking owns applicability, proof, and dispatch selection. Analysis consumes frozen semantic identities and source projections. No later responsibility parses source text, scans adjacent requirements, or inspects another layer's private storage to repeat those decisions.

Final Result

The review found no remaining compatibility parser, standalone conformance identity, capability union, separate associated-binding requirement, optional validation authority, duplicate interface-method search, callable/interface dispatch conflation, order-dependent predicate assembly, or editor reconstruction of implementation semantics. Dynamic interface values, erased callables, interface inheritance, and overload ranking remain explicit non-goals rather than partially implemented paths.