Ownership Representation

This page describes the ownership representation used by checker, MIR lowering, and both backends today.

The canonical model separates:

• type identity (BaseTy)
• access intent at a boundary (AccessMode)
• runtime/local storage representation (MirLocalRepr, MirHeapOwnership)

That split keeps compatibility decisions in one place while preserving backend- specific lowering details where they belong.

Canonical Ownership Model

Shared ownership modeling lives in ruka_types:

• AccessMode: View | MutBorrow | Owned
• BaseTy: pure type identity (StaticArray, DynamicArray, Slice, StaticSlice)
• NormalizedTy: (BaseTy, AccessMode)
• normalize_ty: converts Ty into NormalizedTy
• normalize_ty_with_access: converts one Ty into a boundary-aware normalized form with explicit access mode

Ty remains the semantic type carried across the compiler, but compatibility and boundary logic are expressed in terms of normalized ownership data.

Compatibility Decisions

Compatibility/coercion decisions are centralized in ruka_types:

• ty_coercion_decision: type-to-type compatibility
• boundary_coercion_decision: explicit expected/actual boundary access mode compatibility
• CoercionDecision: Denied | Allowed { exact, check, materialization }

Policy fields are independent so decisions can express combinations:

• check (CheckPolicy) answers whether runtime validation is required
• materialization (MaterializationPolicy) answers whether representation bridging is required

Current runtime-check categories:

• RuntimeCheckKind::LenEquals
• RuntimeCheckKind::LenAtLeast

Current concrete materialization categories:

• MaterializationKind::ViewFromOwned
• MaterializationKind::DynamicArrayFromStaticArray
• MaterializationKind::StaticArrayFromDynamicArray

Checker Usage

Checker call compatibility uses shared boundary coercion decisions. Ownership mode is mapped to normalized access mode at call boundaries, then validated by boundary_coercion_decision.

Primary implementation entry points live in:

• crates/ruka_check/src/checker_calls.rs

MIR Boundary Usage

MIR lowering uses one boundary plan path for call arguments and normalized projection for parameter locals.

• Parameter local projection and ownership-mode mapping: crates/ruka_mir_lower/src/lowerer/helpers.rs
• Call argument planning and compatibility usage: crates/ruka_mir_lower/src/lowerer/call_args.rs

MIR itself exposes boundary helpers so consumers do not duplicate branching:

• MirParamBinding
  • expects_view, expects_mut_borrow, materializes_view_from_owned, requires_materialization
• MirCallArgBinding
  • is_borrowed, is_mutable_borrow, is_owned_move, is_owned_copy, requires_deref_read
• MirAggregateArg
  • is_owned_move, is_owned_copy

Backend ABI Usage

Rust and WASM backends both consume MIR binding helpers rather than re-deriving ownership semantics independently.

Rust:

• emit_internal_call_args
• emit_extern_call_args

WASM:

• emit_call_arg
• call_arg_strategy
• lower_call_family_instr

Notes for Contributors

• Add ownership compatibility behavior in ruka_types coercion APIs first.
• Prefer MIR binding helper predicates over open-coded mode matching.
• Keep mdBook pages as overview and workflow guidance; put API detail in rustdoc.