Ownership & Borrowing in Rust (Key Rust Feature)

1. Introduction

Related Post
📖 If you haven't read it yet, check out the previous blog: Control Flow & Functions in Rust: Beginner’s Guide

Rust’s Ownership & Borrowing system is one of its most powerful and unique features. It ensures memory safety without a garbage collector, making Rust an efficient and safe systems programming language.

In this guide, we will explore:

✅ How ownership works in Rust
✅ Borrowing and the difference between mutable and immutable references
✅ Lifetimes and how they prevent dangling references

Mastering ownership and borrowing is essential for writing efficient, safe, and bug-free Rust code. Let’s dive in! 🚀

2. What Is Ownership?

Ownership is a set of rules that governs how a Rust program manages memory. Unlike garbage-collected languages or manual memory management, Rust ensures memory safety through ownership rules checked at compile time. This means zero-cost safety, as there is no runtime overhead from garbage collection.

2.1 Why Ownership Matters

Memory management is a crucial aspect of programming. Some languages use garbage collection (e.g., Java, Python), which automatically reclaims unused memory. Others (e.g., C, C++) require manual memory management, where developers must explicitly allocate and free memory. Rust, however, enforces ownership rules at compile time to ensure memory safety and efficiency without a garbage collector.

By enforcing ownership, Rust prevents memory leaks, dangling pointers, and data races at compile time. This enables developers to write high-performance, safe, and concurrent programs.

2.2 Ownership Rules

Each value has a single owner – A value in Rust can only have one owner at a time.

There can only be one owner at a time – Ownership of a value can be transferred but never duplicated.

When the owner goes out of scope, the value is dropped – Rust automatically cleans up memory when an owner leaves its scope.

These rules eliminate the need for garbage collection and ensure that memory is always managed safely and efficiently.

fn main() {
    let x = 5; // x is the owner of the value 5
    println!("x: {}", x); // ✅ x is still valid here
} // x goes out of scope, and the memory is cleaned up

In this example, x owns the integer 5. When x goes out of scope at the end of main(), Rust automatically deallocates the memory.

2.3 Transferring Ownership

If we need to use a value in a different part of our program, ownership must be transferred to a new variable or function parameter. This ensures that there is always a clear owner responsible for managing memory.

fn main() {
    let s1 = String::from("Hello");
    let s2 = s1; // Ownership moves to s2, s1 is now invalid
    
    // println!("{}", s1); // ❌ This will cause an error because s1 is no longer valid
    println!("{}", s2); // ✅ This works
}

In the above example, s1 transfers ownership to s2. Since Rust prevents multiple owners of the same value, trying to access s1 after the transfer results in a compilation error.

If we need to retain access to the original value, we must create another owner by explicitly cloning the value:

fn main() {
    let s1 = String::from("Hello");
    let s2 = s1.clone(); // Creates a deep copy, so both s1 and s2 own separate values
    
    println!("s1: {}, s2: {}", s1, s2); // ✅ Both values remain accessible
}

📌 Key Takeaway: When ownership moves, the previous owner loses access to the value. To retain ownership, you must either transfer ownership explicitly or clone the value.

Understanding these rules is crucial for writing safe and performant Rust code. Now, let's explore how ownership interacts with stack and heap memory.

3. The Stack and the Heap

Many programming languages don’t require you to think about the stack and the heap very often. However, in a systems programming language like Rust, whether a value is on the stack or the heap affects how the language behaves and the decisions you need to make.

Both the stack and the heap are parts of memory available to your code at runtime, but they are structured differently:

3.1 Stack Memory

Stores values in order and removes them in Last In, First Out (LIFO) order.

Faster because the memory location is always at the top.

Requires a known, fixed size at compile time.

Examples: Integers, booleans, fixed-size arrays.

3.2 Heap Memory

Used for dynamically sized data.

The memory allocator finds a suitable space and returns a pointer.

Slower access because it requires following a pointer.

Examples: String, Vec<T>, Box<T>.

3.3 Why Ownership Matters More for Heap Memory

Stack-allocated values are automatically cleaned up when they go out of scope.

Heap-allocated values require explicit tracking to avoid memory leaks or double frees.

Rust’s ownership system ensures that heap data is properly allocated and freed.

When your code calls a function, the values passed (including heap pointers) and local variables get pushed onto the stack. When the function ends, those values get popped off the stack automatically.

4. References and Borrowing

Borrowing in Rust allows functions to use a value without taking ownership of it. This is done using references (&T), which come in two types:

Immutable References (&T) – Read-only access.

Mutable References (&mut T) – Allows modification, but enforces strict borrowing rules.

4.1 Immutable References (&T)

Rust allows multiple immutable references as long as no mutable reference exists at the same time.

fn print_length(s: &String) {
    println!("Length: {}", s.len());
}

fn main() {
    let s = String::from("Rust");
    print_length(&s); // Borrowing `s` as an immutable reference
    println!("Original string: {}", s); // ✅ s is still accessible
}

📌 Key Takeaways:

Multiple immutable borrows are allowed simultaneously.

Since print_length() only reads the data, the reference does not modify s.

4.2 Mutable References (&mut T)

Rust allows only one mutable reference at a time to prevent data races.

fn modify(s: &mut String) {
    s.push_str(" World");
}

fn main() {
    let mut s = String::from("Hello");
    modify(&mut s); // Borrowing `s` as a mutable reference
    println!("{}", s); // ✅ Prints: Hello World
}

📌 Key Takeaways:

Only one mutable reference can exist at a time.

Ensures safety by preventing simultaneous mutations.

Borrowing ends when the reference is no longer used, allowing new borrows afterward.

4.3 Mixing Mutable and Immutable References (Not Allowed)

let mut s = String::from("Rust");
let r1 = &s;
let r2 = &s;
let r3 = &mut s; // ❌ ERROR: Cannot have a mutable reference when immutable references exist.

📌 Rust prevents conflicts by enforcing that:

Multiple immutable references are allowed.

Only one mutable reference is allowed.

You cannot mix mutable and immutable references at the same time.

4.4 Dangling References and Rust’s Safety Mechanism

Rust prevents dangling references (references pointing to invalid memory). If a reference outlives the value it refers to, the compiler will generate an error.

fn dangle() -> &String {
    let s = String::from("hello"); // s is created inside the function
    &s // ❌ ERROR: Returning a reference to a local variable
}

📌 Fix: Return the actual String instead of a reference.

fn no_dangle() -> String {
    let s = String::from("hello");
    s // ✅ Moves ownership instead of returning a reference
}

5. What is Dereferencing (*)?

Dereferencing is the process of accessing the actual value that a reference or pointer is pointing to. The * (dereference operator) is used in Rust to retrieve the underlying value.

5.1 When to Use *?

When modifying a mutable reference (&mut T).

When working with smart pointers (Box<T>, Rc<T>, RefCell<T>).

When explicitly dereferencing a raw pointer (*const T, *mut T).

Example: Dereferencing a Mutable Reference

fn modify(s: &mut String) {
    *s = String::from("New Value"); // ✅ Dereferencing allows modification
}

fn main() {
    let mut s = String::from("Hello");
    modify(&mut s);
    println!("{}", s); // Output: New Value
}

📌 Key Takeaway: *s allows modifying or retrieving values from references explicitly.

Example: No Need for * with Methods

fn main() {
    let s = String::from("Hello");
    println!("{}", s.len()); // ✅ No need for `*s`
}

📌 Key Takeaway: Rust automatically dereferences when calling methods or accessing struct fields.

6. Lifetimes in Rust

Lifetimes ensure that references are always valid and prevent dangling references. Rust enforces lifetimes at compile time to guarantee memory safety.

6.1 Why Lifetimes Matter

When functions return a reference, Rust needs to ensure that the reference does not outlive the data it points to. Without lifetimes, references could point to invalid memory, leading to undefined behavior.

Example: Lifetime Annotation

fn longest<'a>(s1: &'a str, s2: &'a str) -> &'a str {
    if s1.len() > s2.len() {
        s1
    } else {
        s2
    }
}

fn main() {
    let string1 = String::from("long string is long");
    let string2 = String::from("xyz");
    let result = longest(string1.as_str(), string2.as_str());

    println!("The longest string is {}", result);
}

📌 Key Takeaway

'a is a generic lifetime parameter.

It tells Rust that s1, s2, and the return reference all share the same lifetime.

This ensures that the returned reference never outlives s1 or s2.

6.2 Common Lifetimes Rules

Each reference has a lifetime—either explicitly defined or inferred by the compiler.

A reference cannot outlive the data it refers to.

Rust enforces lifetimes at compile time, preventing memory-related bugs.

6.3 When Do You Need Explicit Lifetimes?

Rust automatically infers lifetimes in many cases, but explicit annotations are required when:

A function returns a reference.

Multiple input references could have different lifetimes.

6.4 Why Are Lifetimes Generic?

Lifetimes are generic because they allow functions and structs to work with any valid lifetime instead of a single fixed lifetime.

6.5 Owned vs Borrowed Types (Lifetimes vs No Lifetimes)

Example 1: No Lifetimes Needed (Owned i32)

fn increment(value: i32) -> i32 {
    value + 1
}

fn main() {
    let num = 932;
    let result = increment(num);
    println!("Original: {}, Incremented: {}", num, result);
}

📌 Key Takeaway:

i32 is copied, so ownership is not moved.

No lifetimes are needed because no references are involved.

Example 2: Requires Lifetimes (References &i32)

fn largest<'a>(x: &'a i32, y: &'a i32) -> &'a i32 {
    if x > y { x } else { y }
}

fn main() {
    let a = 932;
    let b = 450;
    
    let result = largest(&a, &b);
    println!("Largest number is {}", result);
}

📌 Key Takeaway:

x and y are references (&i32), meaning they do not own the data.

The function returns a reference, which requires lifetimes to ensure validity.

'a ensures that the returned reference remains valid as long as x and y are still in scope.

7. Next Steps

Now that you’ve learned about Ownership & Borrowing, the next step is understanding Structs, Enums, and Pattern Matching, which allow for more complex data structures and control flow in Rust.

Stay tuned for the next blog on Structs, Enums, and Pattern Matching in Rust! 🚀

💡 If you found this helpful, please remember to leave a like! 👍