🦀 Rust Memory Master

# Rust Concept: Ownership

## Rules
1. Each value has exactly one owner
2. When owner goes out of scope, value is dropped
3. Ownership can be transferred (moved) but not shared

## Code Examples
```rust
// Move semantics
let s1 = String::from("hello");
let s2 = s1; // s1 is now invalid (moved)

// Clone for deep copy
let s3 = s2.clone(); // Both s2 and s3 are valid

// Copy types (stack-only primitives)
let x: i32 = 5;
let y = x; // Copy! Both valid (i32 implements Copy)
```

## Compiler Errors
- E0382: use of moved value (accessing s1 after move to s2)

## Common Mistakes
- Confusing Move with Copy: String moves, i32 copies
- Trying to use value after passing to function (implicit move)
- Solution: use .clone() or pass &reference instead

## Related Concepts
Borrowing, Lifetimes, Drop trait, Copy trait

# Rust Concept: Borrowing

## Rules
1. At any time: either ONE &mut T OR any number of &T — never both
2. References must always be valid (no dangling references)
3. NLL (Non-Lexical Lifetimes): borrow ends at last use, not scope end

## Code Examples
```rust
// Immutable reference - multiple allowed
let s = String::from("hello");
let r1 = &s;
let r2 = &s; // Both valid simultaneously

// Mutable reference - exclusive
let mut s = String::from("hello");
let r = &mut s;
r.push_str(" world"); // One mutable ref allowed

// NLL: borrow ends at last use
let mut s = String::from("hello");
let r1 = &s;
println!("{}", r1); // r1's last use
let r2 = &mut s;   // r1 is already gone (NLL)
```

## Compiler Errors
- E0502: cannot borrow as mutable because also borrowed as immutable
- E0499: cannot borrow as mutable more than once at a time
- E0505: cannot move out of variable because it is borrowed

## Common Mistakes
- "Drop or scope-close the immutable ref before creating mutable"
- Forgetting NLL: references can end before scope closes

## Related Concepts
Ownership, Lifetimes, Interior Mutability (RefCell)

# Rust Concept: Lifetimes

## What They Are
Lifetimes are the compiler's way of tracking how long references are valid.
Annotations like 'a express relationships between reference lifetimes —
they don't change how long things live.

## Rules
1. Every reference has a lifetime
2. Lifetime elision rules handle most cases automatically
3. When returning a reference, its lifetime must come from input parameters

## Code Examples
```rust
// Function lifetimes: output tied to inputs
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}

// Struct with reference field
struct Important<'a> {
    part: &'a str,
}
impl<'a> Important<'a> {
    fn announce(&self) -> &str {
        self.part
    }
}

// 'static: valid for entire program
let s: &'static str = "hello world";
```

## Lifetime Elision Rules (auto-inferred)
1. Each input reference gets its own lifetime
2. If exactly one input reference: output gets same lifetime
3. If &self/&mut self: output gets self's lifetime

## Compiler Errors
- E0597: value does not live long enough (dangling reference)
- E0623: lifetime mismatch between function parameters/return

## Common Mistakes
- Adding 'a everywhere when elision handles it
- Confusing lifetime annotations with runtime behavior
- Forgetting that 'a = min(all lifetimes labeled 'a)

## Related Concepts
Ownership, Borrowing, NLL, Higher-Ranked Trait Bounds (for<'a>)