Why Ownership rules in Rust? - Purpose & Use Cases

The Big Idea

What if your program could catch dangerous mistakes before it even runs?

The Scenario

Imagine you are sharing a single book with your friends. Everyone wants to read it, but only one person can hold it at a time. Without clear rules, the book might get lost, damaged, or confused about who has it.

The Problem

Manually tracking who owns or uses data in a program is like keeping a messy list of who has the book. It's easy to forget, mix up, or lose track. This causes bugs like crashes or data errors, making programs unreliable and hard to fix.

The Solution

Ownership rules in Rust act like a clear borrowing system for the book. They make sure only one person owns the data at a time or that others can borrow it safely without confusion. This prevents mistakes and keeps data safe automatically.

Before vs After

✗ Before

let data = String::from("hello");
let data2 = data; // data is moved, but no warning
println!("{}", data); // compile error: use of moved value

✓ After

let data = String::from("hello");
let data2 = data; // ownership moved
// println!("{}", data); // compile error prevents misuse

What It Enables

Ownership rules enable writing safe and efficient programs that catch mistakes before running, saving time and avoiding crashes.

Real Life Example

When building a messaging app, ownership rules ensure messages aren't accidentally deleted or changed while being read by others, keeping conversations clear and safe.

Key Takeaways

Ownership rules track who owns data to prevent errors.

They avoid bugs by enforcing clear data access at compile time.

This leads to safer, more reliable programs without extra manual checks.

Practice

1. What happens when ownership of a variable is moved to another variable in Rust?

easy

A. The original variable becomes invalid and cannot be used.

B. Both variables can be used independently without restrictions.

C. The data is copied and both variables own separate copies.

D. The original variable automatically deletes the data.

Solution

1. Step 1: Understand ownership move

   When ownership moves, the original variable loses its right to access the data.

2. Step 2: Effect on original variable

   The original variable becomes invalid and cannot be used to prevent double free errors.

3. Final Answer:

   The original variable becomes invalid and cannot be used. -> Option A

4. Quick Check:

   Ownership move invalidates old owner = A [OK]

Hint: Ownership move disables old variable usage [OK]

Common Mistakes:

• Thinking ownership move copies data
• Assuming both variables remain valid
• Confusing move with borrowing

2. Which of the following is the correct syntax to borrow a variable immutably in Rust?

easy

A. let ref x = value;

B. let x = value;

C. let x = *value;

D. let x = &value;

Solution

1. Step 1: Identify borrowing syntax

   Immutable borrowing uses the & symbol before the variable.

2. Step 2: Match correct syntax

   let x = &value; correctly borrows value immutably.

3. Final Answer:

   let x = &value; -> Option D

4. Quick Check:

   Immutable borrow uses & = B [OK]

Hint: Use & to borrow immutably [OK]

Common Mistakes:

• Using * for borrowing instead of dereferencing
• Missing & symbol for borrowing
• Confusing mutable and immutable borrow syntax

3. What will be the output of this Rust code?

let s1 = String::from("hello");
let s2 = s1;
println!("{}", s1);

medium

A. Runtime error

B. hello

C. Compilation error

D. Empty string

Solution

1. Step 1: Analyze ownership move

   Assigning s1 to s2 moves ownership, invalidating s1.

2. Step 2: Using invalidated variable

   Printing s1 after move causes a compile-time error because s1 is no longer valid.

3. Final Answer:

   Compilation error -> Option C

4. Quick Check:

   Using moved variable causes compile error = A [OK]

Hint: Using moved variable causes compile error [OK]

Common Mistakes:

• Expecting s1 to print after move
• Confusing move with copy
• Thinking runtime error occurs instead

4. Identify the error in this Rust code snippet:

let s = String::from("hello");
let r1 = &s;
let r2 = &mut s;
println!("{} and {}", r1, r2);

medium

A. No error, code runs fine.

B. Cannot borrow s as mutable because it is already borrowed as immutable.

C. String::from is not a valid function.

D. Cannot print two variables in one println! macro.

Solution

1. Step 1: Check borrowing rules

   Rust forbids mutable borrow if immutable borrow exists simultaneously.

2. Step 2: Identify conflict

   r1 is an immutable borrow; r2 tries mutable borrow causing error.

3. Final Answer:

   Cannot borrow s as mutable because it is already borrowed as immutable. -> Option B

4. Quick Check:

   Mutable borrow conflicts with existing immutable borrow = D [OK]

Hint: Mutable borrow disallowed if immutable borrow exists [OK]

Common Mistakes:

• Ignoring borrow rules and expecting code to run
• Thinking multiple mutable borrows allowed
• Misunderstanding println! macro usage

5. Given this Rust function:

fn take_ownership(s: String) {
    println!("{}", s);
}

fn main() {
    let s = String::from("hello");
    take_ownership(s);
    println!("{}", s);
}

What is the correct way to fix the error without cloning the string?

hard

A. Change the function parameter to borrow the string: fn take_ownership(s: &String)

B. Remove the println! after the function call.

C. Declare s as mutable in main.

D. Use let s = &String::from("hello"); in main.

Solution

1. Step 1: Understand ownership transfer

   Passing s to take_ownership moves ownership, invalidating s in main.

2. Step 2: Use borrowing to avoid move

   Changing parameter to &String borrows s, so ownership stays with main.

3. Step 3: Adjust function call

   Call take_ownership(&s) to pass reference matching new parameter.

4. Final Answer:

   Change the function parameter to borrow the string: fn take_ownership(s: &String) -> Option A

5. Quick Check:

   Borrow parameter to keep ownership in caller = C [OK]

Hint: Borrow in function parameter to keep ownership [OK]

Common Mistakes:

• Trying to use s after move without borrowing
• Removing code instead of fixing ownership
• Confusing mutability with ownership