Rust Programming - Ownership, Borrowing & Lifetimes Flashcards

Question 1

The Three Rules of Ownership

Accepted Answer

1. Each value in Rust has an owner represented by a variable.
2. There can only be **one owner** at a time.
3. When the owner goes out of scope, the value is automatically dropped.

Question 2

Move Semantics

Accepted Answer

When a non-`Copy` variable is assigned to another variable or passed to a function, ownership is transferred (moved). The original variable becomes invalid and cannot be used afterward.

Question 3

`Copy` vs. `Clone` Traits

Accepted Answer

- `Copy`: Implemented for types stored entirely on the stack (e.g., `i32`, `bool`). Bitwise duplicate occurs implicitly without invalidating the source.
- `Clone`: Requires an explicit `.clone()` call to perform a deep, potentially expensive heap allocation duplicate.

Question 4

Immutable Borrowing (`&T`)

Accepted Answer

Allows creating references to data without taking ownership. Multiple immutable references (`&T`) to the same resource can exist simultaneously because reading data concurrently is thread-safe.

Question 5

Mutable Borrowing (`&mut T`)

Accepted Answer

Allows modifying data without taking ownership. Only **one** mutable reference to a piece of data can exist in a given scope at a time.

Question 6

Aliasing XOR Mutability Rule

Accepted Answer

You can have **either** any number of immutable references (`&T`) **OR** exactly one mutable reference (`&mut T`), but never both in the same scope simultaneously. This prevents data races at compile time.

Question 7

Non-Lexical Lifetimes (NLL)

Accepted Answer

An enhancement to Rust's borrow checker where a reference's lifetime ends at the point of its last usage, rather than at the end of the enclosing scope block (`}`).

Question 8

Lifetime Annotations (`'a`)

Accepted Answer

Generics that begin with an apostrophe (e.g., `'a`). They tell the compiler how the lifetimes of different references in a function's parameters and return value relate to each other without changing actual runtimes.

Question 9

The 3 Lifetime Elision Rules

Accepted Answer

Rules used by the compiler to automatically infer lifetimes:
1. Each input reference parameter gets its own lifetime.
2. If there is exactly one input lifetime parameter, it is assigned to all output lifetimes.
3. If there are multiple input lifetimes but one is `&self` or `&mut self`, `self`'s lifetime is assigned to all output lifetimes.

Question 10

The `'static` Lifetime

Accepted Answer

Specifies that the referenced data lives for the entire duration of the running program (e.g., string literals `&'static str`). It can also mean a type parameter bound by owned data that lives as long as needed.

Question 11

Smart Pointer: `Box<T>`

Accepted Answer

Allocates data on the heap rather than the stack. The stack holds a pointer to the heap location. It provides single ownership and fixed size, useful for recursive types or large data structures.

Question 12

Smart Pointer: `Rc<T>`

Accepted Answer

**Reference Counted** smart pointer that enables **multiple ownership** on the heap in **single-threaded** contexts. Keeps track of active references and drops data when the count reaches zero.

Question 13

Smart Pointer: `Arc<T>`

Accepted Answer

**Atomic Reference Counted** smart pointer. Functionally identical to `Rc<T>`, but uses atomic operations to safely enable shared ownership across multiple threads at a slight performance cost.

Question 14

Interior Mutability & `RefCell<T>`

Accepted Answer

A pattern allowing modification of data even when there is an immutable reference to it. `RefCell<T>` enforces Rust's borrowing rules at **runtime** instead of compile time, panicking if rules are violated.

Question 15

The `Rc>` Pattern

Accepted Answer

A common idiom to achieve **multiple mutable owners** for a single piece of data in single-threaded applications (e.g., node graphs or tree structures).

Question 16

`Option<T>` Enum

Accepted Answer

Rust's null-safety primitive representing a value that may or may not exist:
```rust
enum Option<T> {
    Some(T),
    None,
}
```
Forces explicit handling of absent values.

Question 17

`Result<T, E>` Enum

Accepted Answer

Enum used for recoverable error handling:
```rust
enum Result<T, E> {
    Ok(T),
    Err(E),
}
```
Requires handling both success (`Ok`) and failure (`Err`) outcomes explicitly.

Question 18

The `?` (Question Mark) Operator

Accepted Answer

Unwraps `Ok(T)` or `Some(T)` values, or immediately returns early from the current function if the result is an `Err(E)` or `None`. Simplifies error propagation.

Question 19

Deref Trait & Deref Coercion

Accepted Answer

Implementing `Deref` allows customizing the behavior of dereferencing (`*`). **Deref coercion** automatically converts a reference to a type into a reference to another type (e.g., `&String` to `&str`).

Question 20

The `Drop` Trait

Accepted Answer

Allows customizing code execution when a value goes out of scope (Resource Acquisition Is Initialization / RAII). Used to release external resources like files, sockets, or raw memory.

Question 21

`Send` and `Sync` Marker Traits

Accepted Answer

- `Send`: Indicates that ownership of the type can be transferred across thread boundaries safely.
- `Sync`: Indicates that it is safe for multiple threads to access the type via shared references (`&T` is `Send`).

Rust Programming - Ownership, Borrowing & Lifetimes

Cards in this deck

Related Flashcard Sets

Rust Programming Language - Ownership, Borrowing & Lifetimes

Rust Programming - Ownership, Borrowing & Memory Safety

HSK 2 - Intermediate Chinese Vocabulary & Grammar

Genetics - Mendelian Inheritance & Population Genetics