Who owns a record's data

A run over a million rows reads each record’s fields over and over; every predicate, every projection, every coercion starts by looking at a cell. So one question decides the engine’s hot path: when code reads a field, who keeps owning that data, and does the read copy it or just point at it? You just took a Value apart with an exhaustive match; now the question is what happens to that Value when you hand it around. The Rust tool that answers it is ownership: every value has exactly one owner, handing it off moves it (the source goes invalid), and lending it with & is a borrow that copies nothing and keeps the owner intact. Borrowing pays off twice, in order. First, safety (the borrow checker allows either many shared readers or one writer, never both, and never lets a reference outlive what it points to, all at compile time). Then performance as the consequence (no copy, so reading a field a million times costs nothing). This is where the engine lives; The Rust Book, ch. 4 is the canonical treatment if you want ownership from first principles.

Prerequisites

• Reading a Value

→

Leads to

• Missing cells & fallible parses

What you’ll be able to do

• State the borrow checker’s one rule (either many readers or one writer, never both).
• Distinguish move, borrow, and clone, and predict which one a given line performs.
• Predict whether a value is still usable after it has been moved out, and read the compiler error when it isn’t.
• Explain why FieldResolver::resolve hands back a borrow of a field (&Value) rather than a copy.

New terms in this lesson (each is also expanded inline at the point you first need it):

• ownership: exactly one owner per value, no garbage collector.
• move: assigning or passing transfers ownership; the source goes invalid.
• borrow: &value, used without taking ownership; safe, and cheap.
• clone: an explicit, possibly-expensive deep copy you opt into.

Predict first

✋ Predict first

Given `let status = Value::Text(String::from("active")); let moved = status;`, after that second line, does `read(&status)` compile? Write down yes or no and the one-word reason before revealing.

Decide on your answer before you open the reveal — committing a guess is what makes it stick.

Reveal the answer

No. It does not compile. The line let moved = status; is a move: ownership of the Value transfers from status to moved, and status is left holding nothing. Touching status afterward, even just to borrow it with &status, is a use-after-move, and the compiler rejects it:

error[E0382]: borrow of moved value: `status`

The wrong mental model is “assignment makes a copy, so both variables are usable.” That’s true for small Copy types like i64, but a Value::Text owns a heap-allocated String, so it is not Copy. Assigning it moves it instead of duplicating it, precisely so two variables never both think they own the same allocation. If you genuinely wanted two independent values you’d ask for it out loud with .clone(). Hold that distinction, move versus clone, because the rest of the lesson is built on it.

The engine reads fields by borrowing

When CXL evaluates status == "active", it has to read the status field of the record. The trait that resolves a field name to its value is FieldResolver:

clinker-record ·resolver.rs ·FieldResolver trait @19acdcb4

pub trait FieldResolver {
    fn resolve(&self, name: &str) -> Option<&Value>;
    //                              ^^^^^^^^^^^^^^^^
    //                              a BORROW of the value, not a copy
}

That return type, Option<&Value>, is the whole lesson. &Value is a borrow of the value living inside the record. The resolver doesn’t hand back a Value (which would mean copying it out); it hands back a window onto the one that’s already there. CXL can read status, compare it, and move on without ever duplicating it. (We’ll cover the Option part, what the None means, in the next lesson.)

What a clone would cost

Why does this matter so much? Because copying a Value isn’t always cheap. A Value::Integer is a few bytes, sure. But a Value::String owns its text and a Value::Array owns a whole Vec. Cloning those allocates. Now multiply by every field access, of every record, in a million-row file. Borrowing is free; cloning is a tax. So the engine’s rule is: borrow to read, and only pay for a clone at the one spot that genuinely needs to keep a value (a topic we finish in the zero-copy lesson).

Worked → completion → faded

You met move, borrow, and clone above. Now you run them, fill a gap, and write the whole thing, one new idea per rung.

Worked: see all three on one value

Here is a fully annotated, runnable example. Each line is labeled with which of the three operations it performs. Run it, then uncomment the line after the move and watch the borrow checker explain that status no longer holds anything.

rust // editable

reset ▶ run

#[derive(Debug, Clone)]
enum Value {
  Integer(i64),
  Text(String), // owns its bytes — cloning this allocates
}

fn read(v: &Value) {            // borrows: just looks, takes no ownership
  println!("read {v:?}");
}

fn main() {
  let status = Value::Text(String::from("active"));

  read(&status);              // BORROW — status is still ours afterward
  read(&status);              // BORROW again — many readers are fine

  let kept = status.clone();  // CLONE — a second, independent allocation
  let moved = status;         // MOVE — ownership transfers to `moved`
  // read(&status);           // uncomment: error[E0382] — `status` was moved out

  println!("kept = {kept:?}, moved = {moved:?}");
}

#[derive(Debug, Clone)] enum Value { Integer(i64), Text(String), // owns its bytes — cloning this allocates } fn read(v: &Value) { // borrows: just looks, takes no ownership println!("read {v:?}"); } fn main() { let status = Value::Text(String::from("active")); read(&status); // BORROW — status is still ours afterward read(&status); // BORROW again — many readers are fine let kept = status.clone(); // CLONE — a second, independent allocation let moved = status; // MOVE — ownership transfers to `moved` // read(&status); // uncomment: error[E0382] — `status` was moved out println!("kept = {kept:?}, moved = {moved:?}"); }

The two read(&status) calls are the borrow checker’s “many readers” rule in action: nothing here writes, so any number of shared & borrows coexist. The .clone() is the one line that allocates a fresh String; the move is the one line that retires status.

Completion: name what each line does

This compiles, but two annotations are missing. Each // ??? marks a line. Decide whether it is a borrow, a move, or a clone, and why last_seen is still usable on the final line while owned_copy came from a deliberate allocation. Predict before you reveal.

rust // editable

reset ▶ run

#[derive(Debug, Clone)]
enum Value {
  Integer(i64),
  Text(String),
}

fn length_of(v: &Value) -> usize {   // borrows v
  match v {
      Value::Text(s) => s.len(),
      Value::Integer(_) => 0,
  }
}

fn main() {
  let last_seen = Value::Text(String::from("2026-06-23"));

  let n = length_of(&last_seen);   // ??? (1)
  let owned_copy = last_seen.clone(); // ??? (2)

  println!("len {n}, still have: {last_seen:?}, copy: {owned_copy:?}");
}

#[derive(Debug, Clone)] enum Value { Integer(i64), Text(String), } fn length_of(v: &Value) -> usize { // borrows v match v { Value::Text(s) => s.len(), Value::Integer(_) => 0, } } fn main() { let last_seen = Value::Text(String::from("2026-06-23")); let n = length_of(&last_seen); // ??? (1) let owned_copy = last_seen.clone(); // ??? (2) println!("len {n}, still have: {last_seen:?}, copy: {owned_copy:?}"); }

💡 Hint 1

Line (1) passes &last_seen; the & is the tell. Line (2) calls .clone() explicitly. One of these leaves last_seen owning its String; the other makes a second, independent String. Neither one retires last_seen, which is why the final println! can still print it.

Show solution

let n = length_of(&last_seen);      // (1) BORROW — &last_seen lends a window; ownership stays put
let owned_copy = last_seen.clone(); // (2) CLONE — a brand-new String is allocated alongside the original

Because neither line is a move, last_seen is still the owner of its Value on the last line, so printing it is fine. Contrast the worked example, where let moved = status; did move and the later use was rejected. Borrow and clone both leave the source intact; only a move retires it.

Faded: write the function and trigger the error

Now write it yourself, with only a skeleton. The goal: a function summarize that borrows a Value and returns an owned String describing it (so the caller keeps its Value), then a main that borrows the same value twice, makes one clone, and finally moves it, and a commented-out line that would be a use-after-move if you uncommented it.

rust // editable

reset ▶ run

#[derive(Debug, Clone)]
enum Value {
  Integer(i64),
  Text(String),
}

// TODO: borrow the Value (so the caller keeps ownership) and return an owned String.
// Hint: `match` on the borrowed value, then build a String with format!.
fn summarize(v: &Value) -> String {
  todo!()
}

fn main() {
  let cell = Value::Text(String::from("active"));

  // TODO: borrow `cell` twice via summarize, print both results.
  // TODO: make one clone and bind it to `kept`.
  // TODO: move `cell` into `moved`.
  // TODO: add a commented-out summarize(&cell) AFTER the move that would not compile.

  todo!()
}

#[derive(Debug, Clone)] enum Value { Integer(i64), Text(String), } // TODO: borrow the Value (so the caller keeps ownership) and return an owned String. // Hint: `match` on the borrowed value, then build a String with format!. fn summarize(v: &Value) -> String { todo!() } fn main() { let cell = Value::Text(String::from("active")); // TODO: borrow `cell` twice via summarize, print both results. // TODO: make one clone and bind it to `kept`. // TODO: move `cell` into `moved`. // TODO: add a commented-out summarize(&cell) AFTER the move that would not compile. todo!() }

Show solution

fn summarize(v: &Value) -> String {
    match v {
        Value::Integer(n) => format!("integer {n}"),
        Value::Text(s) => format!("text of {} bytes", s.len()),
    }
}

fn main() {
    let cell = Value::Text(String::from("active"));

    println!("{}", summarize(&cell)); // borrow — cell unaffected
    println!("{}", summarize(&cell)); // borrow again — many readers, fine

    let kept = cell.clone();          // clone — independent allocation
    let moved = cell;                 // move — cell is retired here
    // println!("{}", summarize(&cell)); // error[E0382]: borrow of moved value: `cell`

    println!("kept = {kept:?}, moved = {moved:?}");
}

summarize takes &Value, so each call only borrows; that is what lets you call it twice and still clone and move afterward. The exhaustive match inside it is the same exhaustiveness rule from the previous lesson: drop the Integer arm and this won’t build. Uncomment the last summarize(&cell) and the compiler points at exactly the move that retired cell.

Why-bridge: borrowing is the engine’s hot-path default

Why does the engine reach for a borrow at nearly every field read? Because the alternative is a copy, and copies cost. Reading is the most common thing the engine does: every predicate, every projection, every coercion starts by looking at a Value. If each look duplicated the value, a Value::String or Value::Array would re-allocate on every touch, and the per-record cost would scale with the data, not the work.

A borrow sidesteps that: resolve returns &Value, the caller reads through the reference, and the original stays exactly where it is. The single owner, the record, keeps the value alive for as long as the borrow needs it; the borrow checker proves at compile time that no reader ever outlives the record it points into.

Retrieval checkpoint

✓ Checkpoint

// quick check

After `let moved = status;` (where status holds a Value::Text), what happens if the next line is `read(&status);`?

• It compiles; &status just borrows the value again
• It fails to compile: status was moved into `moved`, so there is nothing left to borrow (error E0382)
• It compiles but prints an empty value

// quick check

At any one moment, the borrow checker lets a value have:

• Many shared readers (&), or exactly one writer (&mut), never both at once
• Any number of &mut writers, as long as they're on different lines
• One reader and one writer simultaneously, as long as they don't conflict

// quick check

What's the cost of cloning a Value::String or Value::Array, versus borrowing it?

• Both are free
• Cloning allocates new heap memory; borrowing is free
• Borrowing is more expensive because of reference counting

// quick check

Two engineers debate move semantics. Which statement is the MISCONCEPTION to correct?

• Assigning a non-Copy value moves it, leaving the source unusable; you call .clone() if you want an independent second value
• Assignment always copies, so both the source and the destination stay usable afterward
• A small Copy type like i64 is duplicated on assignment, so both variables remain usable

// quick check

Spaced recall from the match lesson: the summarize() function in the faded task matches over a borrowed &Value. Why won't it compile if you delete the Value::Integer arm?

• Because borrowing a Value requires a complete match
• Because match on an enum must be exhaustive: every variant needs an arm, or the compiler refuses to build
• Because Value::Integer is the default arm

// quick check

Spaced recall from the Value cell: resolve() returns &Value, a borrow of one cell. What IS a Value in Clinker?

• An open set of types any crate can extend at runtime
• A closed enum: one of a fixed set of cell shapes (Null, Bool, Integer, Float, String, …)
• Always a heap-allocated String

You should be able to:

• You can state the borrow checker's rule: many readers (&) or one writer (&mut), never both at once
• You can label a given line as a move, a borrow, or a clone, and say whether the source is still usable after it
• You predicted whether a moved-from value still compiles, and can read the E0382 use-after-move error
• You explained why resolve() returns a borrow (&Value) rather than an owned Value

Verify in the checkout:

grep -n 'fn resolve' crates/clinker-record/src/resolver.rs

Connections

You understand why records flow on borrows: ownership stays with the record, reads go through cheap &Value windows, and a clone is a deliberate cost you pay only when a value must outlive its source. Next: the two types that encode “maybe absent” and “maybe failed”, namely Option and Result, which you already half-met in that Option<&Value>.

Prerequisites

• Reading a Value

→

Leads to

• Missing cells & fallible parses

Go deeper on the Rust (optional, one-directional; for the same concepts taught from first principles in The Rust Book):

• Want ownership and move from first principles, with no engine framing? Read the docs →
• Want the borrow checker drilled on standalone examples? Read the docs →

Glossary terms used: ownership, move, borrow, clone.

Mark this lesson complete