IntermediateOwnership in depth

Lab: Ownership in depth

Consolidate your understanding of references, slices, lifetimes, and error handling through scenario-based questions.

Lab · optionalRustIntermediate15 min

Recommended first

Error handling

By the end of this lesson you will be able to:

Apply borrowing rules to multi-step code scenarios
Reason about lifetime relationships without running code
Trace error propagation through ? chains

This lab checks your understanding of the ownership-in-depth module through scenario questions. No compiler required — the goal is to reason about Rust's rules before you try them. When you're uncertain, make a prediction, then verify in a real project.

Part 1: Borrowing rules

Knowledge check

1.
The following code compiles. True or false?
```
let mut v = vec![1, 2, 3];
let first = &v[0];
v.push(4);
println!("{}", first);
```
True — you are only reading first, not writing through itFalse — v.push() requires a mutable borrow while first holds a shared borrow
2.
Which change would make the previous snippet compile?
Change let first = &v[0] to let first = v[0]Use println! before v.push(4) and remove the later println!Add a clone: let first = v[0].clone()Both b and c
3.
What does a "fat pointer" mean in the context of a Rust slice like &[i32]?
A pointer that has been heap-allocatedA pointer paired with a length — two words wide instead of oneA pointer that implements the Fat traitA raw pointer cast to a larger integer type

Part 2: Lifetime scenarios

Knowledge check

1.
Does this function need explicit lifetime annotations?
```
fn greet(name: &str) -> String {
    format!("Hello, {}!", name)
}
```
Yes — it takes a reference so it always needs annotationsNo — the return type is an owned String, not a reference. No relationship to annotate.No — but only because of rule 3 (self lifetime)Yes — format! internally creates a reference
2.
Which elision rule covers this signature?
```
fn first(v: &[i32]) -> &i32
```
Rule 1 only — each input gets its own lifetimeRules 1 and 2 — one input lifetime is assigned to the outputRule 3 — &self lifetime propagates to outputNo rule applies — this needs explicit annotations
3.
A struct Wrapper<'a> { val: &'a str } guarantees that Wrapper cannot be used after the &str it holds is dropped.
TrueFalse

Part 3: Error propagation

Knowledge check

Putting it together

The three topics in this module are deeply connected. Slices are borrowed windows — their validity is tracked by lifetimes. Error handling with ? uses From conversions that involve owned types, not references. The ownership model is the common thread: every Rust feature is designed so the compiler can prove your program won't corrupt memory.

If any of these questions surprised you, revisit the corresponding lesson. The borrow checker's error messages are precise — the fastest way to build intuition is to write code that you expect to fail, read the error, and understand why it's right.

Where to go next

Next module: Types & traits — starting with enums and pattern matching, where you'll see how Result and Option are just two examples of a much richer pattern.

Finished reading? Mark it complete to track your progress.

Error handling

Propagate failures with Result<T,E>, the ? operator, and custom error types — Rust's exception-free approach to robust programs.

Enums and pattern matching

Model domain states with data-carrying enums and exhaustively handle them with match, if let, and destructuring.

Lab: Ownership in depth

Part 1: Borrowing rules

Knowledge check

Part 2: Lifetime scenarios

Knowledge check

Part 3: Error propagation

Knowledge check

Putting it together

Where to go next

On this page