The ownership model: move, copy, borrow

Absolutely. The ownership model is the heart of Rust’s memory safety without garbage collection. It eliminates memory bugs at compile time—not by runtime checks, but by enforcing strict rules about how data is accessed and transferred.

Let’s break down the three core concepts: Move, Copy, and Borrow—with clear examples and practical implications.

🔑 Core Principle:

Each piece of data has exactly one owner. When the owner goes out of scope, the data is automatically cleaned up.

This prevents memory leaks and use-after-free bugs by design.

1. 🔄 Move — Transfer of Ownership

In Rust, assignment transfers ownership by default (unlike C++ or Go). The original variable is invalidated.

Example:

fn main() {
    let s1 = String::from("Hello");
    let s2 = s1; // 👉 `s1` is MOVED to `s2`

    // println!("{}", s1); // ❌ COMPILE ERROR!
    // "value borrowed here after move"
    
    println!("{}", s2); // ✅ OK
}

Why?
String owns heap-allocated data. If both s1 and s2 pointed to it, both would try to free it → double-free crash.
Rust prevents this by invalidating s1 on move.

✅ Safety: No dangling pointers. No double-frees.
⚠️ Effect: You can’t accidentally use stale data.

2. 📋 Copy — Cheap, Implicit Duplication

Some types are automatically copied on assignment (instead of moved) because they’re cheap and live entirely on the stack.

These types implement the Copy trait (e.g., integers, booleans, floats, tuples of Copy types).

Example:

fn main() {
    let x = 5;
    let y = x; // 👉 `x` is COPIED (not moved)

    println!("x = {}, y = {}", x, y); // ✅ Both work!
}

Why is i32 copied but String moved?

• i32 is just 4 bytes on the stack → cheap to duplicate.

• String owns a pointer to heap data → expensive and unsafe to duplicate implicitly.

✅ You never have to call .clone() for simple values.
🚫 You cannot implement Copy for types that manage resources (files, sockets, heap memory).

3. 🤝 Borrow — Temporary Access Without Ownership

Instead of moving data (which makes the original unusable), you can borrow it using references (&T for read, &mut T for write).

Immutable Borrow (Read-Only)

fn main() {
    let s = String::from("Karachi");
    let len = calculate_length(&s); // 👉 Borrow `s` (no move!)
    
    println!("Length of '{}' is {}", s, len); // ✅ `s` still valid
}

fn calculate_length(s: &String) -> usize {
    s.len() // `s` is a reference — doesn’t own the data
} // `s` goes out of scope here, but the *owner* still owns it

Mutable Borrow (Read-Write)

fn main() {
    let mut s = String::from("Hello");
    change(&mut s); // 👉 Mutable borrow
    println!("{}", s); // "Hello, Rust!"
}

fn change(s: &mut String) {
    s.push_str(", Rust!");
}

🔒 Borrowing Rules (Enforced at Compile Time!)

1. You can have either:

   • One or more immutable references (&T)

   • OR exactly one mutable reference (&mut T)

2. References must always be valid (no dangling pointers).

❌ This fails to compile:

let mut s = String::from("test");
let r1 = &s;
let r2 = &s;
let r3 = &mut s; // ❌ Can't borrow mutably while immutable refs exist
println!("{}, {}, {}", r1, r2, r3);

💡 Practical Implications for Reliable Code

🛠️ When to Use What?

✅ Summary

🦀 The borrow checker is your ally—it’s strict early so you never debug memory corruption at 3 AM.