Codebase / Memory management

Memory management

Moth is reference-semantic by default, copy-explicit and move-inferred. It omits explicit reference types and lifetime syntax, not references themselves.

Moth keeps the source model small. Reads are shared, copies are explicit and mutation has to announce itself.

Borrow validation enforces exclusive mutation and optional transfer safety. Lifetime-region validation enforces one lifetime owner and legal retained edges. A GC representation keeps execution practical while ownership analysis leaves room for future allocation and deterministic-drop optimisations.

Shared access vs copy

Existing values use shared, read-only access by default. Binding a new name to an existing value doesn't copy it. Use copy when you need an independent value.

Shared aliases use last-potential-use activity, not pure lexical lifetime. After the final potential use of a shared alias, later mutation may proceed.

    items ~= {"a", "b"}
    shared_items = items

    change(~items)       -- invalid: shared_items is used again
    inspect(shared_items)
    

    items ~= {"a", "b"}
    shared_items = items
    inspect(shared_items)

    change(~items)       -- valid: shared_items has no later potential use
    

    items ~= {"a", "b"}
    copied_items = copy items

    change(~items)
    inspect(copied_items)
    

Exclusive access

~place requests temporary mutation-capable access to an existing mutable place. It isn't a move marker or a type identity. Fresh rvalues satisfy ordinary mutable parameters without source ~. Mutable receivers still require an existing mutable place.

    change({"fresh"})
    

Lifetime owners

Every runtime allocation has exactly one semantic lifetime owner. Multiple bindings or fields may alias that allocation without becoming additional owners.

An object may retain a reference only when the referenced allocation belongs to the same lifetime region or to a region statically known to outlive the retaining object.

The compiler rejects illegal sibling sharing and cross-region cycles even under GC. GC is a permitted representation for a statically legal topology, not a way to accept invalid retained edges.

Declared group / into syntax is accepted end-state design with implementation deferred. See Declared memory groups for the source contract and Lifetime regions and escape validation for the general topology model.

How the compiler layers it

            source access and copy rules
                -> AST access-mode, placement and freshness validation
                -> validated HIR with explicit places and control flow
                -> borrow validation and optional transfer facts
                -> lifetime-region and escape validation
                -> build-owned reachability, lifecycle roots and target planning
                -> GC, region, ownership-aware or other validated backend lowering
        

Detailed pages

• Access and aliasing: shared reads, explicit copies and ~ access
• Borrow validation: roots, joins, optional transfer safety and facts
• Lifetime regions and escape validation: one owner, retained edges, escapes and region topology
• Declared memory groups: accepted deferred group / into semantics and hard destination lifetimes
• Ownership and drops: inferred transfer, unified ABI and conditional destruction
• Runtime and backend lowering: GC baseline and ownership-aware backend paths

Current support

See Progress matrix for what is implemented today.