Reading a field without copying — lifetimes

The engine reads a field by handing back a borrow into the record (resolve returns &Value), so evaluating an expression walks a record’s cells without copying a single one. That zero-copy read is what keeps the hot path cheap, and it ties the whole data layer together. You met the borrow itself back in Ownership: move & borrow, where &value let you read without taking ownership. But a borrow raises an obvious danger: what if the record is gone and you still hold the reference? The Rust tool that rules that out is the lifetime; we use just enough of it to read the engine’s zero-copy reader, and The Rust Book, ch. 10.3 is the canonical treatment if you want lifetimes from first principles.

Prerequisites

• Sharing & boxing

→

Leads to

• Planning & Expressions (Overview)

What you’ll be able to do

• Read a lifetime annotation like RecordView<'a, S> and name what the 'a ties together.
• Explain how a lifetime prevents a dangling reference, and what the compiler does instead of crashing at runtime.
• Predict whether a borrow that outlives its source compiles, and read the borrow-checker error when it doesn’t.
• Distinguish a zero-copy read from the one place the engine must pay for an owned copy, and say why each is correct.

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

• lifetime: a name ('a) for how long a borrow stays valid.
• zero-copy: read a value in place through a borrow, copying nothing.
• borrow: &value, use it without taking ownership (from Ownership: move & borrow).
• reference validity: a reference is only good while its target is still alive.

Predict first

✋ Predict first

A type holds a borrow into record storage: struct RecordView<'a, S> { storage: &'a S, index: u64 }. You build a RecordView from some storage, then the storage is dropped while the view is still in scope and you try to read through it. Does that program compile? Write down yes/no and one word for what stops it (or what crashes) 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, and nothing crashes at runtime because the program never runs. The 'a in RecordView<'a, S> is a lifetime: it ties the view to the storage it borrowed from. The compiler tracks that the view’s borrow must end no later than the storage’s life, so a view used after its storage is dropped is a use-after-free the borrow checker rejects:

error[E0505]: cannot move out of `storage` because it is borrowed

The wrong mental model is “this is a runtime danger I have to remember to avoid,” the same way a dangling pointer is a bug you hunt with a debugger in C. In Rust it isn’t a runtime danger at all: a view onto dropped storage is a program that won’t compile. The lifetime is the compiler’s bookkeeping that makes a whole class of dangling-read bugs unrepresentable. Hold that: a missed lifetime is a build error, never a crash, and the rest of the lesson earns it.

A lifetime is “how long this borrow is valid”

A reference can’t outlive the thing it points at. A lifetime (written 'a) is the compiler’s name for “the span during which this borrow is valid.” Most of the time you never write one; the compiler infers them. But when a type holds a borrow, it must say so, and that annotation is what guarantees the borrow can’t dangle. The property it protects is plain: reference validity, a reference is good only while its target is alive.

The engine’s zero-copy field reader is exactly such a type. RecordView<'a, S> is a tiny, Copy handle (a pointer plus an index) that borrows into record storage for the lifetime 'a:

clinker-record ·record_view.rs ·RecordView type @19acdcb4

#[derive(Clone, Copy)]
pub struct RecordView<'a, S: RecordStorage + ?Sized> {
    storage: &'a S,   // borrows the record storage for the lifetime 'a
    index: u64,       // which record
}

The 'a ties the view to the storage it came from. The compiler will not let a RecordView outlive that storage, so a view onto a record that’s been dropped is not a runtime crash you debug, it’s a program that won’t compile. The storage it reads through is itself a trait, so the same view works over the real arena in production and a stub in tests:

clinker-record ·storage.rs ·RecordStorage trait @19acdcb4

pub trait RecordStorage: Send + Sync {
    fn resolve_field(&self, index: u64, name: &str) -> Option<&Value>;
    // ... resolve_qualified, available_fields, record_count
}

Zero-copy, and the one clone

Put the pieces together. Reading a field returns &Value (a borrow, Ownership: move & borrow), the absent case is None (Option and Result), and shared backing data lives behind Arc (Smart pointers). So evaluating a CXL expression (coalescing, comparing, filtering) walks through fields without copying a single one. That is zero-copy: the string "active" is read in place, compared, and discarded; it’s never duplicated. A copy is paid exactly once, and only at the spot that must keep a value past the borrow (an output that writes it, say), not on every read along the way.

There’s even a small trick for the absent case: rather than allocate an empty value to return, the resolver can hand back a borrow of a single shared static “null” value, a reference with a 'static lifetime that’s always valid, so None-ish reads cost nothing either. ('static is the one lifetime with a name you’ll see often: it means “valid for the whole program,” which is exactly true of a value baked into the binary.)

Lifetimes stop a dangling read

rust // editable

reset ▶ run

#[derive(Debug)]
enum Value { Text(String) }

// Returns a borrow INTO the record — tied to the record's lifetime.
fn resolve<'a>(record: &'a [Value], index: usize) -> Option<&'a Value> {
  record.get(index)
}

fn main() {
  let record = vec![Value::Text(String::from("active"))];
  let field = resolve(&record, 0);   // borrows from `record`
  println!("{field:?}");             // fine: record is still alive here

  // Try this: move the drop earlier.
  // drop(record);
  // println!("{field:?}");          // won't compile — `field` would dangle
}

#[derive(Debug)] enum Value { Text(String) } // Returns a borrow INTO the record — tied to the record's lifetime. fn resolve<'a>(record: &'a [Value], index: usize) -> Option<&'a Value> { record.get(index) } fn main() { let record = vec![Value::Text(String::from("active"))]; let field = resolve(&record, 0); // borrows from `record` println!("{field:?}"); // fine: record is still alive here // Try this: move the drop earlier. // drop(record); // println!("{field:?}"); // won't compile — `field` would dangle }

Run it, then uncomment the two lines. The borrow checker refuses to compile a program where field could be read after record is gone. That refusal, at compile time and every time, is what lets the engine borrow fearlessly.

Worked → completion → faded

You met lifetimes on a real engine type above. Now you read one, fill a gap in one, and write a borrowing type from scratch. One new idea per rung.

Worked: a view that borrows, fully annotated

Here is a self-contained RecordView-shaped type that mirrors the engine’s: a small Copy handle holding a borrow plus an index, with the lifetime spelled out on every line that carries it. Run it and watch the view read a field without copying anything.

rust // editable

reset ▶ run

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

// A tiny handle that BORROWS storage for the lifetime 'a — like the engine's RecordView.
// It owns nothing; it only looks through the borrow.
#[derive(Clone, Copy)]
struct RecordView<'a> {
  storage: &'a [Value],   // the borrow, valid for 'a
  index: usize,           // which cell to read
}

impl<'a> RecordView<'a> {
  // The returned &Value borrows for 'a too — tied to the same storage.
  fn field(&self) -> Option<&'a Value> {
      self.storage.get(self.index)
  }
}

fn main() {
  let record = vec![Value::Integer(7), Value::Text(String::from("active"))];

  let view = RecordView { storage: &record, index: 1 }; // borrows record
  println!("read in place: {:?}", view.field());        // zero-copy: no Value is duplicated

  // record is still alive and unmoved — the view only ever borrowed it.
  println!("record still owned here: {:?}", record);
}

#[derive(Debug)] enum Value { Integer(i64), Text(String) } // A tiny handle that BORROWS storage for the lifetime 'a — like the engine's RecordView. // It owns nothing; it only looks through the borrow. #[derive(Clone, Copy)] struct RecordView<'a> { storage: &'a [Value], // the borrow, valid for 'a index: usize, // which cell to read } impl<'a> RecordView<'a> { // The returned &Value borrows for 'a too — tied to the same storage. fn field(&self) -> Option<&'a Value> { self.storage.get(self.index) } } fn main() { let record = vec![Value::Integer(7), Value::Text(String::from("active"))]; let view = RecordView { storage: &record, index: 1 }; // borrows record println!("read in place: {:?}", view.field()); // zero-copy: no Value is duplicated // record is still alive and unmoved — the view only ever borrowed it. println!("record still owned here: {:?}", record); }

The 'a appears three times, on the struct, on the impl, and on the returned &'a Value, and they all name the same span: as long as record is alive. The view is Copy (it’s just a pointer and an integer), so handing it around costs nothing, and it never owns the data it reads.

Completion: add the missing lifetime

This type is one annotation short of compiling. The field stores a borrow, but the struct doesn’t yet declare the lifetime that borrow lives for. Add it: declare a lifetime parameter on the struct and use it on the storage field, so the borrow has a name.

rust // editable

reset ▶ run

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

// TODO: this struct holds a borrow but never names its lifetime.
// Add a lifetime parameter and apply it to the storage field.
#[derive(Clone, Copy)]
struct FieldPeek /* <-- needs <'a> */ {
  storage: &[Value], // <-- this borrow needs a named lifetime: &'a [Value]
  index: usize,
}

fn main() {
  let record = vec![Value::Text(String::from("active"))];
  let peek = FieldPeek { storage: &record, index: 0 };
  println!("{:?}", peek.storage.get(peek.index));
}

#[derive(Debug)] enum Value { Integer(i64), Text(String) } // TODO: this struct holds a borrow but never names its lifetime. // Add a lifetime parameter and apply it to the storage field. #[derive(Clone, Copy)] struct FieldPeek /* <-- needs <'a> */ { storage: &[Value], // <-- this borrow needs a named lifetime: &'a [Value] index: usize, } fn main() { let record = vec![Value::Text(String::from("active"))]; let peek = FieldPeek { storage: &record, index: 0 }; println!("{:?}", peek.storage.get(peek.index)); }

💡 Hint 1

A struct that stores a & must declare the lifetime as a generic parameter, exactly like RecordView<'a, S> did. The name goes in angle brackets after the struct name, then on the borrowed field: struct FieldPeek<'a> { storage: &'a [Value], … }.

Show solution

#[derive(Clone, Copy)]
struct FieldPeek<'a> {
    storage: &'a [Value], // the borrow now has a name: 'a
    index: usize,
}

Declaring <'a> and writing &'a [Value] is the type saying out loud “I hold a borrow, and here is the span it’s valid for.” That single annotation is what lets the compiler prove no FieldPeek ever outlives the record it points into: the same guarantee RecordView<'a, S> gives the engine.

Faded: write a borrowing type and trigger the dangling-read error

Now write one yourself from a skeleton. The goal: a Cursor<'a> that borrows a slice of Values and reads the cell at its position without copying it, then a main that builds one, reads through it while the data is alive, and a commented-out line that would be a dangling read if you uncommented it (drop the data, then read through the cursor).

rust // editable

reset ▶ run

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

// TODO: declare a lifetime 'a, store a borrow of the data, and a position.
#[derive(Clone, Copy)]
struct Cursor /* <'a> */ {
  // data: &'a [Value],
  // pos: usize,
}

// TODO: read the borrowed cell at pos, returning a borrow that lives for 'a.
// fn current(...) -> Option<&Value> { ... }

fn main() {
  let data = vec![Value::Integer(1), Value::Text(String::from("active"))];

  // TODO: build a Cursor borrowing &data at pos 1, print current().
  // TODO: add a commented-out block that drops data then reads through the
  //       cursor — the line that would dangle.

  todo!()
}

#[derive(Debug)] enum Value { Integer(i64), Text(String) } // TODO: declare a lifetime 'a, store a borrow of the data, and a position. #[derive(Clone, Copy)] struct Cursor /* <'a> */ { // data: &'a [Value], // pos: usize, } // TODO: read the borrowed cell at pos, returning a borrow that lives for 'a. // fn current(...) -> Option<&Value> { ... } fn main() { let data = vec![Value::Integer(1), Value::Text(String::from("active"))]; // TODO: build a Cursor borrowing &data at pos 1, print current(). // TODO: add a commented-out block that drops data then reads through the // cursor — the line that would dangle. todo!() }

Show solution

#[derive(Clone, Copy)]
struct Cursor<'a> {
    data: &'a [Value], // borrow, valid for 'a
    pos: usize,
}

impl<'a> Cursor<'a> {
    fn current(&self) -> Option<&'a Value> {
        self.data.get(self.pos) // borrows for the same 'a — no copy
    }
}

fn main() {
    let data = vec![Value::Integer(1), Value::Text(String::from("active"))];

    let cur = Cursor { data: &data, pos: 1 }; // borrows data
    println!("{:?}", cur.current());          // zero-copy read

    // drop(data);                  // retire the data early...
    // println!("{:?}", cur.current()); // error[E0505]: cannot move out of `data`
    //                                  //   because it is borrowed by `cur`
}

Cursor<'a> borrows; it never owns the Values, so current() reads them in place. The 'a on the struct, the impl, and the returned &'a Value all name the span the borrow is valid: data’s life. Uncomment the two lines and the compiler points at exactly the drop that would make the cursor dangle. There is no path to a runtime dangling read.

Real-source grounding

Here is the engine type the worked example mirrors. RecordView<'a, S> is the zero-copy field reader: a Copy handle that borrows storage for 'a and reads fields through it.

clinker-record ·record_view.rs ·RecordView type @19acdcb4

#[derive(Clone, Copy)]
pub struct RecordView<'a, S: RecordStorage + ?Sized> {
    storage: &'a S,   // borrows storage for 'a — the view can't outlive it
    index: u64,
}

What the compiler enforces: a RecordView can never be used after the S it borrows is gone. Drop the storage while a view still references it and the program does not build; there is no code path that reads a dropped record through a view.

What a junior might misread: thinking the 'a makes the view own a copy of the storage (it doesn’t; the view owns nothing, it only borrows), or thinking a missing lifetime is a runtime risk to test for (it’s a compile error; the dangling program never runs). The ?Sized and the S: RecordStorage bound also let one view type work over the real arena and a test stub alike: storage is a trait, not a concrete type.

The storage it reads through is that trait:

clinker-record ·storage.rs ·RecordStorage trait @19acdcb4

pub trait RecordStorage: Send + Sync {
    fn resolve_field(&self, index: u64, name: &str) -> Option<&Value>;
    // returns Option<&Value> — a BORROW (lesson 11) of the cell, never a copy
    // ... resolve_qualified, available_fields, record_count
}

That Option<&Value> return is the zero-copy read in one line: Option for “maybe the field is absent” (the Option/Result lesson), &Value for “borrowed, not duplicated” (the ownership lesson). The lifetime on that borrow is tied, through the view, all the way back to the storage’s life.

Why-bridge: lifetimes are what make zero-copy safe, not just fast

Why does the engine read everything through borrows and lifetimes instead of handing back owned Values? Because zero-copy is only worth doing if it’s also safe. Borrowing a field instead of cloning it saves an allocation on every read (the ownership lesson), but a borrow with no guarantee behind it would just be a dangling-pointer bug waiting to happen, the exact class of crash Rust exists to rule out.

The lifetime is that guarantee. RecordView<'a, S> can read a field with no copy because the 'a proves, at compile time, that the view never outlives the storage it reads. The engine gets the performance of pointer-chasing C with none of its dangling-read risk: the fast path and the safe path are the same path.

Apply: predict the compiler, then fix the dangling return

This is a generation task, not recognition. Read the function below. It’s meant to be broken: it tries to return a borrow of a value that the function is about to drop.

// WON'T COMPILE — kept here as a deliberate counterexample.
fn first_field() -> &'static Value {
    let record = vec![Value::Text(String::from("active"))]; // owned here, dropped at the }
    &record[0] // returning a borrow of something about to die
}

enum Value { Text(String) }

Predict the compiler first. What error does the &record[0] return produce, and why?

Show the compiler's answer

error[E0515]: cannot return reference to local variable `record`
  --> src/main.rs
   |
   |     &record[0] // returning a borrow of something about to die
   |     ^^^^^^^^^^ returns a reference to data owned by the current function

record is owned by first_field and is dropped when the function returns, so any borrow of it would dangle the instant the caller received it. There is no valid lifetime to give the returned &Value: it would have to outlive the data it points at. The fix is to make the caller own the data and lend it in, so the borrow’s lifetime is tied to something that actually outlives the call:

// The caller owns the record; the borrow is valid for as long as the caller's 'a.
fn first_field<'a>(record: &'a [Value]) -> &'a Value {
    &record[0]
}

This is the entire safety promise of lifetimes in one error message: the compiler will not let you return a borrow that outlives its data. It’s the same rule RecordView<'a, S> rides on: a view, or a returned &Value, is only ever valid for as long as the storage it came from.

Retrieval checkpoint

✓ Checkpoint

// quick check

What does the lifetime 'a in RecordView<'a, S> guarantee?

• That the view is copied for thread safety
• That the view cannot outlive the record storage it borrows from: no dangling reference, enforced at compile time
• That fields are cloned before being read

// quick check

A view onto a record whose storage has been dropped: what actually happens?

• The program crashes at runtime with a use-after-free, like a dangling pointer in C
• The program does not compile: the borrow checker rejects the view outliving its storage
• The view silently reads garbage from the freed memory

// quick check

Across a CXL evaluation, how many times is a field's Value::String copied?

• Once per field access
• At most once, only where a value must be kept past its borrow; reads along the way are zero-copy
• Never, under any circumstances

// quick check

Spaced recall from the ownership lesson: RecordStorage::resolve_field returns Option<&Value>, not Option<Value>. Why the & inside?

• To make the Option smaller in memory
• So reading a field borrows the existing cell instead of copying it out, and that borrow is exactly what a lifetime keeps valid
• Because Option can only hold references

// quick check

Spaced recall from the smart pointers lesson: the shared static "null" value handed back for an absent field has a 'static lifetime. What does 'static mean here?

• The value is mutable and shared across threads
• The reference is valid for the whole program (true of a value baked into the binary), so it never dangles
• The value is dropped as soon as the function returns

You should be able to:

• You can read RecordView<'a, S> and say what the 'a ties together (the view to the storage it borrows)
• You can explain how a lifetime prevents a dangling reference, and that a missed lifetime is a compile error, not a runtime crash
• You added a missing lifetime to a borrowing struct, and wrote a borrowing type from scratch
• You predicted the 'cannot return reference to local variable' error and gave a fix that ties the borrow to the caller
• You can name the one place the engine pays for an owned copy, and why every other read is zero-copy

Verify in the checkout:

grep -n 'struct RecordView' crates/clinker-record/src/record_view.rs
grep -n 'trait RecordStorage' crates/clinker-record/src/storage.rs

Connections: and the end of Data & Representation

You can now read a lifetime annotation, explain how it forbids a dangling reference at compile time, write a type that borrows, and name the one place the engine pays for an owned copy. That closes Data & Representation. You’ve gone from “a record is a row of cells” to the real machinery: a 32-byte closed Value, exhaustive match, borrow-don’t-copy field access, Option/Result for absence and failure, Arc-shared schemas and context, and lifetimes that make all the borrowing provably safe. Planning & Expressions moves up a layer: how the engine turns YAML and CXL into the validated CompiledPlan you’ve been running.

Prerequisites

• Sharing & boxing

→

Leads to

• Planning & Expressions (Overview)

Go deeper on the Rust (optional; The Rust Book teaches borrowing from first principles and folds lifetimes into that chapter rather than a standalone one):

• Want the borrow checker and reference validity drilled on standalone examples? Read the docs →

Glossary terms used: lifetime, zero-copy, borrow, reference validity.

Mark this lesson complete