106 Rust Interview Questions and Answers (2026)

A String is a growable, heap-allocated, owned UTF-8 buffer; a &str is a borrowed view (a fat pointer) into some existing UTF-8 data that it does not own.

• String owns its data:

  • On the stack it is three words: a pointer to a heap buffer, a length, and a capacity.

  • It can grow/mutate, and frees its heap buffer when dropped.

• &str borrows data:

  • It is a two-word fat pointer: a pointer plus a length (no capacity, no ownership).

  • It points into a String, a string literal ('static), or any UTF-8 region.

• Ownership relationship:

  • A &str is bound by the lifetime of the data it borrows; the owner must outlive it.

  • String derefs to &str, so functions should take &str for flexibility and return/store String when ownership is needed.

• String literals like "hi" have type &'static str and live in the binary's read-only data.

The stack stores fixed-size, last-in-first-out data tied to function calls and is very fast; the heap stores dynamically-sized or long-lived data accessed through a pointer. Rust decides which to use based on whether a type's size is known at compile time.

• The stack:

  • Holds values with a known, fixed size: integers, bool, arrays, structs of stack types.

  • Push/pop is just moving a pointer, so allocation is essentially free and freed automatically at scope end.

• The heap:

  • Used when size is unknown at compile time or data must outlive the current frame (Vec, String, Box<T>).

  • The allocator finds space and returns a pointer; the pointer/len/capacity metadata usually lives on the stack.

• How Rust ties them together:

  • An owner on the stack manages its heap allocation; when the owner is dropped, the heap memory is freed.

  • This makes heap cleanup deterministic without a GC.

An array [T; N] has a fixed length known at compile time and is normally stored inline (often on the stack), while a Vec<T> is growable and always stores its elements in a heap buffer.

• Array [T; N]:

  • Length N is part of the type and fixed at compile time.

  • Stored inline where it's declared (on the stack for locals), no allocation, no pointer indirection.

• Vector Vec<T>:

  • Length is dynamic; elements live in a heap allocation it can resize.

  • The stack only holds the pointer/len/capacity handle.

• When to use which:

  • Array: small, fixed-count data known up front, maximum speed, no heap.

  • Vec: count varies at runtime or you need to grow/shrink.

  • Both deref to a slice &[T], giving a common interface.

Use Box<T> to put a single value on the heap when you need a known pointer size, indirection, or ownership of a trait object; when the Box goes out of scope it drops the inner value and frees its heap allocation automatically.

• Common reasons to box:

  • Recursive types: a type that contains itself needs a fixed size, so the inner part goes behind a Box (e.g. a linked list or tree node).

  • Trait objects: Box<dyn Trait> stores a value of unknown size behind a pointer.

  • Moving a large value cheaply: transfer a pointer instead of copying the whole payload.

• What happens at scope end:

  • Box is an owning smart pointer; dropping it runs the inner value's Drop and then deallocates the heap memory.

  • Deterministic, no GC; like C++ unique_ptr.

• Cost: One heap allocation plus pointer indirection; otherwise a thin, single-owner wrapper.

Use &T to borrow data you don't own without moving it; use Box<T> when you need to own heap-allocated data, such as recursive types or trait objects whose size isn't known at compile time.

• &T is a borrow:

  • Points to data owned elsewhere; doesn't allocate, doesn't transfer ownership, and is bound by the borrow checker's lifetime rules.

  • Cheap and the default choice for passing data into functions.

• Box<T> is an owning pointer:

  • Allocates T on the heap and owns it; dropping the Box frees the memory.

  • Needed for recursive types (a node containing itself) so the type has a finite, known size.

  • Enables trait objects (Box<dyn Trait>) and moving large values cheaply (only the pointer moves).

• Rule of thumb: Just reading borrowed data: use &T. Need ownership on the heap or an unsized/recursive type: use Box<T>.

If type inference has nothing else to go on, let x = 5 defaults to i32. The designers chose i32 as a safe, generally fast default for integer arithmetic.

• Inference comes first: The compiler uses surrounding context (function signatures, annotations) to pick the type; only if undetermined does it fall back to the default.

• Why i32:

  • Signed, so it handles negatives and avoids surprising wrap-on-subtraction bugs.

  • 32 bits is a good balance: fast on virtually all CPUs and rarely the bottleneck, even on 64-bit machines.

• Floats parallel this: An undetermined floating-point literal defaults to f64.

Both declare immutable named values, but a const is inlined wherever it's used (no fixed address), while a static is a single value living at a fixed memory location for the program's entire lifetime.

• const:

  • Conceptually a compile-time constant that gets substituted (inlined) at each use site; there's no guaranteed single address.

  • Always immutable and must be a constant expression.

• static:

  • Has a fixed memory address and 'static lifetime; all references point to the same location.

  • Can be mutable via static mut, but accessing it requires unsafe due to data-race risk.

• Choosing between them: Use const for plain constant values; use static when you need a single, addressable instance (e.g. a large shared buffer or something whose identity matters).

Both are enums for handling absence or failure, but Option<T> models a value that may or may not exist (no error context), while Result<T, E> models an operation that can fail and carries a reason E for the failure.

• Option<T>:

  • Variants Some(T) and None; absence is expected and not an error.

  • Use for: optional fields, a lookup that may miss (HashMap::get), or "nothing to return" cases.

• Result<T, E>:

  • Variants Ok(T) and Err(E); failure needs explanation.

  • Use for: I/O, parsing, anything where the caller should know why it failed.

• Idiom and interop:

  • Use ? to propagate either; with Result the error converts via From.

  • Convert between them: Option::ok_or turns None into an Err; Result::ok discards the error to get an Option.

Default provides a zero-argument way to construct a sensible default value via T::default(). You derive it on structs/enums whose fields are themselves Default, so you get a ready-made baseline instance.

• The trait: One method: fn default() -> Self. Numbers default to 0, bool to false, collections/String to empty.

• Deriving it: #[derive(Default)] works when every field implements Default; it fills each field with its own default.

• When to use:

  • Config/builder structs where most fields have natural defaults.

  • With struct update syntax: Config { port: 8080, ..Default::default() }.

  • As a generic bound, and to back unwrap_or_default().

• Custom defaults: If the derived value isn't right, implement Default by hand to set specific non-zero values.

A lifetime is a compile-time region during which a reference is valid; lifetime annotations don't change how long data lives, they just describe relationships between references so the borrow checker can prove no reference outlives its data. The compiler needs explicit annotations when those relationships are ambiguous.

• What lifetimes are:

  • Every reference has a lifetime; usually inferred. Written 'a and attached as &'a T.

  • They are purely a static check: no runtime cost, erased after compilation.

• What annotations express: They tie outputs to inputs: fn longest<'a>(a: &'a str, b: &'a str) -> &'a str says the result lives no longer than both inputs.

• Why the compiler asks for them:

  • When a function returns a reference derived from multiple inputs, the compiler can't guess which one it borrows from, so you must state it.

  • Structs holding references need a lifetime so the struct can't outlive the borrowed data.

• Special lifetimes: 'static means valid for the whole program (e.g. string literals).

The borrow checker is a compile-time analysis that enforces Rust's ownership rules on references, guaranteeing memory safety without a garbage collector. Its core rule: at any point you may have either one mutable borrow or any number of shared (immutable) borrows of a value, never both, and no borrow may outlive the data it points to.

• The aliasing rule: Many &T (read-only) OR exactly one &mut T (exclusive) at a time. This prevents data races and iterator invalidation.

• Validity / outlives: A reference must not outlive the value it borrows, so no dangling pointers.

• Non-lexical lifetimes (NLL): A borrow ends at its last actual use, not at the end of the scope, so code that's clearly safe compiles.

• How it analyzes: It tracks the lifetimes/regions of borrows and checks no two conflicting borrows overlap. It's conservative: it rejects anything it can't prove safe.

• Escape hatches: When rules are too strict, interior mutability (RefCell) moves the check to runtime, and unsafe opts out where you uphold invariants manually.

The borrow checker is the part of the Rust compiler that enforces the ownership and borrowing rules: it statically verifies that references never outlive the data they point to and that aliasing and mutation never happen at the same time.

• What it enforces:

  • Each value has one owner; references either share (&T) or exclusively borrow (&mut T).

  • A borrow must not outlive its referent.

• Problems prevented at compile time:

  • Dangling references (use-after-free): a reference to freed or out-of-scope data.

  • Data races: simultaneous aliasing and mutation across threads.

  • Iterator invalidation: mutating a collection while iterating it.

  • Double frees: enforced by single ownership and move semantics.

• Zero runtime cost: All checks happen during compilation, so there's no garbage collector or runtime overhead.

A &T is a shared (immutable) reference allowing read-only access, while &mut T is an exclusive reference allowing mutation; the core rule is that you may have many shared references OR exactly one mutable reference, never both at once.

• Shared reference &T:

  • Many can coexist; read-only (no mutation through it unless interior mutability like Cell/RefCell is used).

  • Implies the data won't change while the reference is alive.

• Mutable reference &mut T:

  • Exactly one at a time, and no shared references may coexist with it.

  • Grants exclusive read/write access.

• Why the restriction:

  • Guarantees no aliasing-plus-mutation, which eliminates data races and surprising mutation through a stale alias.

  • Borrows are scoped by NLL (non-lexical lifetimes): a borrow ends at its last use, so a shared borrow and a later mutable borrow are fine if they don't overlap.

All three extract a success value from a Result or Option, but unwrap() and expect() panic on failure while ? returns the error to the caller instead of crashing.

• unwrap(): Returns the inner value or panics with a generic message on Err/None.

• expect(msg): Same as unwrap() but panics with your custom message, which documents the assumption and aids debugging.

• The ? operator:

  • On Ok(v)/Some(v) it yields v; on Err(e)/None it early-returns that error from the function (no panic).

  • Only usable in a function whose return type is compatible (Result or Option).

• Rule of thumb: use ? to propagate recoverable errors; reserve expect() over unwrap() for cases you've proven cannot fail.

Use Result for recoverable errors the caller should decide how to handle, and panic! for unrecoverable situations that signal a bug or broken invariant where continuing makes no sense.

• Result<T, E>:

  • Models expected, recoverable failure (file missing, bad input, network error).

  • Returned to the caller so they can retry, fall back, or report it.

• panic!:

  • Aborts the current thread by unwinding (or aborts the process), meant for unrecoverable bugs.

  • Triggered explicitly or by failed assumptions: unwrap(), out-of-bounds indexing, failed assertions.

• When each is appropriate:

  • Library code should almost always return Result and let the application decide.

  • Panic for programmer errors / broken invariants, in tests, and in prototypes.

  • A panic means "this should never happen"; a Result means "this might happen, deal with it."

Rust has no null; instead a value that may be absent has type Option<T>, so the compiler forces you to handle the None case before you can touch the inner value, eliminating accidental null dereferences.

• Absence is encoded in the type: Option<T> is either Some(T) or None; a plain T can never be null.

• You can't use the value without checking: To get the T out you must match, use if let, or call a combinator: the compiler rejects code that ignores None.

• Errors become compile-time, not runtime: The "billion-dollar mistake" of a null dereference is caught at build time instead of crashing in production.

• Ergonomic handling: Methods like unwrap_or(), map(), and ? keep the checked-access pattern concise.

Both extract the success value and panic on failure; the only difference is the message: unwrap() panics with a generic message, while expect(msg) panics with your message explaining why failure was thought impossible.

• The difference:

  • unwrap(): shortest, but the panic only tells you which line, not the intent.

  • expect("..."): documents the invariant, so logs explain the assumption that was violated. Generally preferred over unwrap().

• When it's acceptable in production:

  • When failure is genuinely impossible by construction (e.g. parsing a hardcoded constant, a lock you know isn't poisoned).

  • During early startup/config where crashing is the correct response to a misconfiguration.

  • Prefer expect() with a message stating the invariant: "why I expect this to succeed."

• When to avoid: On any value derived from user input, I/O, or network: use ? or proper matching so a bad input doesn't crash the service.

Ownership is Rust's compile-time memory model: every value has exactly one owner, and the value is dropped when that owner goes out of scope. This gives memory safety without a garbage collector.

1. Each value has a single owner: A variable binds to a value and is responsible for it.

2. There can only be one owner at a time: Assigning or passing a non-Copy value moves ownership; the old binding becomes invalid.

3. When the owner goes out of scope, the value is dropped: Rust automatically calls drop, freeing heap memory and other resources deterministically.

Borrowing (references via & and &mut) lets you access a value without taking ownership, governed by the borrow checker.

Both produce a duplicate, but Copy is an implicit, cheap, bitwise duplication that happens automatically on assignment, while Clone is an explicit, potentially expensive duplication you request with .clone().

• Copy is implicit and stack-only:

  • A marker trait: assigning or passing the value copies its bits and leaves the original valid.

  • Only for types made entirely of Copy fields (e.g. integers, bool, char).

• Clone is explicit and may be deep:

  • Can duplicate heap data (e.g. String allocates a new buffer).

  • Copy is a supertrait of Clone, so every Copy type is also Clone.

• Why not everything is Copy:

  • Types owning a resource (heap memory, file handle) can't be safely bit-copied: two owners would double-free.

  • A type with a Drop impl can never be Copy.

When you assign or pass a value, Rust either moves it or copies it depending on whether the type implements Copy. A move transfers ownership and invalidates the source; a copy duplicates the bits and leaves both valid.

• Move semantics (the default):

  • Applies to non-Copy types like String and Vec.

  • Ownership transfers; using the original afterward is a compile error.

  • Only the stack handle (pointer/len/cap) is copied; the heap data is not duplicated.

• Copy semantics:

  • Applies to Copy types (small, stack-only values).

  • The bits are duplicated and both source and destination remain usable.

• Key insight: The mechanism is the same bitwise copy; the difference is whether the original stays valid (Copy) or is invalidated (Move).

Shadowing declares a new variable that reuses an existing name with let, creating a fresh binding that hides the previous one. Mutation changes the value stored in the same binding.

• Shadowing creates a new binding:

  • Each let makes a new variable; the old one is hidden in that scope.

  • Can change the type (e.g. String to its length as a number).

  • Works without mut; the new binding can be immutable.

• Mutation reuses the same binding:

  • Requires mut; the variable's type must stay the same.

  • Changes the value in place, no new variable is introduced.

• When to use shadowing: Transforming a value through stages while keeping one descriptive name, often with a type change.

Because usize implements Copy and String does not. Passing a Copy type duplicates its bits, so the caller keeps a valid value; passing a String moves ownership into the function.

• usize is a simple stack value:

  • It's a fixed-size integer with no heap allocation, so it's Copy.

  • Copying the bits is cheap and safe: two independent copies cause no double-free.

• String owns heap data:

  • It holds a pointer, length, and capacity referring to a heap buffer.

  • Bit-copying would create two owners of the same buffer, risking a double-free, so Rust moves instead.

• How to keep using a String: Pass a reference (&String or &str) to borrow, or call .clone() to deep-copy.

All three match a pattern, but they differ in how many arms they handle and whether they loop: if let handles one pattern once, while let repeats it in a loop, and match handles all patterns exhaustively.

• if let:

  • Runs a block when a value matches one pattern, ignoring the rest; optionally with an else branch.

  • Concise sugar for a match with one meaningful arm and a _ => () catch-all.

• while let:

  • Loops as long as the pattern keeps matching, stopping at the first non-match.

  • Common for draining iterators or popping from a collection (while let Some(x) = stack.pop()).

• match:

  • Must cover every possible case (exhaustive), and can return a value from each arm.

  • Use it when you genuinely care about multiple variants, not just one.

• Rule of thumb: reach for if let/while let to avoid noisy single-arm matches; use match when several outcomes matter.

A match must handle every possible value of the matched type so no case is silently forgotten; the compiler rejects the code if any pattern is missing, turning a whole class of runtime bugs into compile errors.

• Exhaustiveness is checked at compile time: The compiler knows all variants of an enum and errors if an arm is missing, naming the uncovered case.

• It forces you to handle the awkward cases: You can't ignore None or an error variant by accident, the way an unhandled if branch lets you in other languages.

• It makes refactors safe: Add a new enum variant and every non-exhaustive match stops compiling, showing exactly where logic must be updated.

• You opt out explicitly with _:

  • A wildcard arm satisfies exhaustiveness deliberately, so ignoring cases is a visible choice, not an oversight.

  • Note: #[non_exhaustive] enums from other crates require a _ arm so future variants don't break you.

Rust organizes code into a tree of modules rooted at the crate, and items are private to their module by default; you opt into visibility with pub and its restricted forms like pub(crate).

• Modules form a tree:

  • Declared with mod (inline or in a file/folder), and items are reached via paths like crate::net::client.

  • use brings a path into scope to avoid repeating it.

• Private (the default): An item is visible only within its module and that module's descendants; child modules can see their parents' private items.

• pub: Visible wherever the containing module is visible, including to outside crates (if the path to it is also public).

• pub(crate):

  • Visible anywhere in your own crate but not exported to consumers: ideal for internal helpers.

  • Related forms: pub(super) (parent module) and pub(in path) (a specific ancestor).

Rust has testing built into the language and Cargo: you mark functions with #[test], and cargo test compiles a special test harness that runs them, while #[cfg(test)] keeps test-only code out of normal builds.

• #[test]:

  • Marks a function as a test; it passes if it returns normally and fails if it panics (e.g. via assert! / assert_eq!).

  • Helpers: #[should_panic], #[ignore], and returning Result to use ?.

• #[cfg(test)]:

  • Conditionally compiles a module only during testing, so unit tests and mocks add nothing to release binaries.

  • Conventionally a mod tests with use super::*; so it can reach private items.

• Test placement: Unit tests live alongside code (can test private fns); integration tests live in tests/ and only see the public API.

• Execution: Tests run in parallel by default and capture stdout unless they fail (or you pass --nocapture).

A debug build (cargo build) prioritizes fast compilation and debuggability with no optimization, while a release build (cargo build --release) turns on optimizations for fast, small runtime code at the cost of slower compiles.

• Debug profile (dev):

  • opt-level = 0: no optimization, fast to compile, easy to step through in a debugger.

  • Includes debug symbols and runtime debug_assertions (including integer overflow checks that panic).

  • Outputs to target/debug.

• Release profile:

  • opt-level = 3: inlining, dead-code elimination, loop optimizations, etc.

  • Debug assertions and overflow checks are off by default (overflow wraps), so it can be much faster but behaves differently on edge cases.

  • Slower to build; outputs to target/release.

• Customizable: Both profiles are tunable in Cargo.toml via [profile.dev] / [profile.release] (e.g. lto, codegen-units, panic).

• Always benchmark on --release: debug numbers are misleadingly slow.

Zero-cost abstractions means high-level constructs compile to machine code as efficient as hand-written low-level code: you don't pay (at runtime) for what you don't use, and what you do use you couldn't write faster by hand.

• The philosophy:

  • Abstractions exist for the programmer's clarity but are erased or inlined by the compiler.

  • No mandatory runtime, no GC pauses, no hidden boxing.

• Iterators are the classic example:

  • A chain like .iter().map(...).filter(...).sum() compiles to a tight loop equivalent to a manual for loop with indexing.

  • Closures are monomorphized and inlined, so no per-element function-call overhead.

• Other examples:

  • Generics use monomorphization (separate specialized code per type) instead of runtime dispatch.

  • Option<T> and the ownership/borrow system exist only at compile time, adding no runtime cost.

• Caveat: "zero-cost" is about runtime; you may trade compile time and binary size (code bloat from monomorphization).

Rust uses ownership with compile-time-tracked scopes: each value has a single owner, and when the owner goes out of scope the value is deterministically dropped. This is essentially compiler-enforced RAII, similar to C++ but with stronger guarantees against misuse.

• Ownership and scopes:

  • Every value has one owner; freeing happens when that owner leaves scope, calling Drop.

  • Moves transfer ownership; the borrow checker prevents use-after-move and dangling references at compile time.

• No GC means deterministic, predictable cleanup: No background collector, no pauses, allocation lifetimes are known statically.

• Comparison to C++ RAII:

  • Same idea: destructors run at scope exit (Drop ~ C++ destructor, Box<T> ~ unique_ptr, Rc/Arc ~ shared_ptr).

  • Difference: Rust's borrow checker statically forbids use-after-free, double-free, and data races, which C++ RAII allows you to write by mistake.

• Escape hatches when needed: Reference counting (Rc, Arc) for shared ownership, with runtime cost only where used.

A &[T] is a non-owning fat pointer (pointer + length) into a contiguous sequence, while a Vec<T> is an owning three-word handle (pointer + length + capacity) that manages its own heap buffer.

• &[T] (a slice):

  • Two words: a pointer to the first element and a length; no capacity.

  • Borrows data it doesn't own and cannot grow; it's just a window.

  • It can point into a Vec, an array, or any contiguous region.

• Vec<T>:

  • Three words: pointer, length, capacity, all on the stack pointing to a heap buffer.

  • Owns the buffer, can grow/shrink, and frees it on drop.

• Relationship:

  • Vec<T> derefs to &[T], so a Vec can be passed wherever a slice is expected.

  • Prefer &[T] in function parameters: it accepts both vectors and arrays without taking ownership.

A Rust enum is a sum type (a tagged union / algebraic "OR" type): a value is exactly one of several variants, and each variant can carry its own data. This is fundamentally richer than C/C++ or Java enums, which are essentially named integer constants.

• Sum type semantics: The set of possible values is the sum of each variant's possible values; combined with structs (product types), Rust enums form full algebraic data types.

• Variants carry data: Each variant can hold different typed payloads, e.g. Option<T> and Result<T, E> are enums.

• Difference from C++/Java:

  • C/C++ enums are just integer labels with no attached data.

  • Java enums are singleton object instances; flexible but not a typed union.

  • Rust enums are checked by match, which the compiler forces to be exhaustive, giving safety and expressiveness.

Rust has no garbage collector because it manages memory at compile time through ownership and borrowing: the compiler knows exactly when each value is dropped, so memory is freed deterministically without a runtime collector.

• How it works instead: Ownership rules (one owner, scoped lifetimes) and the borrow checker insert deallocation (drop) at known points, RAII-style.

• Benefits:

  • No GC pauses, predictable latency: critical for systems, embedded, and real-time code.

  • Low, deterministic memory overhead and no runtime needed.

  • Memory and data-race safety guaranteed at compile time.

• Trade-offs:

  • Steeper learning curve: the borrow checker rejects programs that would be fine under a GC.

  • Some data structures (graphs, cyclic references) are harder; you reach for Rc, RefCell, or unsafe.

  • Reference cycles via Rc can still leak (no collector to reclaim them).

A function pointer (fn type) is a single machine word holding the function's address: 8 bytes on a 64-bit platform. The number of parameters or the signature does not change its size.

• It's just an address:

  • It stores where the code lives, not the arguments; arguments are passed at call time via registers/stack.

  • So fn(i32) -> i32 and fn(i32, i32, i32) -> i32 are both one pointer wide.

• Contrast with closures: A bare fn pointer is thin (one word). A &dyn Fn trait object is a fat pointer (two words: data + vtable).

• Check it: std::mem::size_of::<fn(i32, i32) -> i32>() returns 8 on a 64-bit target.

Static dispatch resolves which concrete function to call at compile time via generics (monomorphization); dynamic dispatch resolves it at runtime via a vtable behind a dyn Trait. Static is faster but produces more code; dynamic is more flexible but adds a small runtime cost.

• Static dispatch (generics):

  • The compiler monomorphizes: it generates a specialized copy of the function for each concrete type used.

  • Calls are direct and inlinable, so zero runtime overhead, at the cost of larger binaries (code bloat) and longer compile times.

• Dynamic dispatch (dyn Trait):

  • The value is a fat pointer (data + vtable); the actual method is looked up in the vtable at runtime.

  • Adds an indirect call (cheap but defeats inlining) plus a pointer indirection.

  • Enables heterogeneous collections like Vec<Box<dyn Trait>> and keeps binary size smaller.

• How to write each: fn f<T: Trait>(x: T) or impl Trait gives static dispatch; &dyn Trait / Box<dyn Trait> gives dynamic dispatch.

The Deref trait lets a type customize the behavior of the dereference operator *, so a smart pointer can behave like the value it wraps. Deref coercion is the compiler automatically converting a reference to such a type into a reference to its target when needed, e.g. &String to &str.

• The trait:

  • Implementing Deref requires a type Target and fn deref(&self) -> &Self::Target; *x becomes *(x.deref()).

  • DerefMut does the same for mutable references.

• Deref coercion:

  • When you pass &T where &U is expected and T: Deref<Target = U>, the compiler inserts the conversion automatically.

  • It chains: &Box<String> can coerce all the way to &str.

  • Resolved entirely at compile time, so there's no runtime cost.

• Why it matters: It lets smart pointers (Box, Rc, String) transparently expose the methods of their target without manual dereferencing.

An associated type is a single output type fixed per implementation, while a generic type parameter lets the trait be implemented many times for the same type with different parameters. Associated types express "there is exactly one related type here"; generic parameters express "this works for any of these types."

• Associated type:

  • Declared with type Item; inside the trait; each impl picks exactly one concrete type.

  • A type can implement the trait only once, so the related type is determined by the implementer, not the caller.

  • Best when the relationship is functional: Iterator has one Item per iterator.

• Generic type parameter:

  • Written trait Foo<T>; a type can implement Foo<A> and Foo<B> separately.

  • The caller (or context) chooses the parameter, enabling multiple impls.

  • Example: From<T> is implemented many times for one type, one per source T.

• Practical effect:

  • Associated types reduce type clutter and improve inference (you don't restate the type at every use site).

  • Generics give flexibility at the cost of needing to specify or infer the parameter.

Both hide a concrete type behind a trait, but impl Trait is static dispatch with the type resolved at compile time (zero cost, single type), while Box<dyn Trait> is dynamic dispatch through a heap allocation and vtable, allowing heterogeneous or runtime-chosen types.

• impl Trait:

  • Monomorphized: the compiler knows the exact concrete type, so calls are static (often inlined), no allocation.

  • Limitation: in return position it must return one concrete type across all paths.

  • Great for returning closures or iterators without naming unwriteable types.

• Box<dyn Trait>:

  • Dynamic dispatch via vtable; heap allocation and a pointer indirection per call.

  • Can hold different concrete types at runtime: e.g. a Vec<Box<dyn Trait>> of mixed types.

  • Lets you return different types from different branches and reduces code bloat from monomorphization.

• Rule of thumb: Default to impl Trait for performance and a single type; reach for Box<dyn Trait> when you need heterogeneity, runtime polymorphism, or to store the value in a collection/struct field.

The Newtype pattern wraps an existing type in a single-field tuple struct to give it a new, distinct identity. It is used to add type safety, attach behavior, or bypass the orphan rule, all at zero runtime cost.

• What it is: A wrapper like struct Meters(f64); that the compiler treats as a separate type from the inner value.

• Why use it:

  • Type safety: Meters and Seconds can't be mixed even though both wrap f64.

  • Bypass the orphan rule: implement an external trait on an external type by wrapping it locally (e.g. Display on a Vec).

  • Encapsulation: hide the inner representation and expose only chosen methods, enforcing invariants.

• Cost and ergonomics:

  • Zero runtime overhead: the wrapper compiles away to the inner type.

  • Downside: you lose the inner type's methods unless you re-expose them or derive/implement Deref.

Trait bounds constrain a generic type to types that implement specific traits, telling the compiler which methods are available. Unlike class inheritance, they describe capabilities (behavior a type provides) rather than an is-a hierarchy, and they are resolved by monomorphization with no runtime cost by default.

• How bounds work:

  • Written inline (fn f<T: Display>) or in a where clause; multiple bounds combine with +.

  • Inside the function you may use only methods guaranteed by the bounds, checked at compile time.

• How it differs from inheritance:

  • No base-class hierarchy: a type can satisfy many unrelated traits without a common ancestor.

  • Composition over inheritance: behavior is added by implementing traits, not by extending a parent.

  • Static dispatch by default (monomorphized per concrete type), versus the runtime virtual dispatch typical of Java/C++ inheritance.

  • No data inheritance: traits carry behavior, not fields; supertraits (trait A: B) require another trait but don't share state.

In return position, impl Trait lets the function (not the caller) pick a single hidden concrete type, while a generic return type <T: Trait> lets the caller choose the type. Despite looking similar, who controls the type is the key difference.

• impl Trait in return position:

  • The callee fixes one concrete type, often unnameable (closures, iterator chains).

  • Caller can't influence it and can't choose among types; all return paths must yield the same type.

  • Static dispatch, no allocation.

• Generic return type:

  • Form fn make<T: Default>() -> T: the caller decides T, and the function must be able to produce any such T.

  • This is rarely what you want for returns: the body usually constructs a specific type, which conflicts with letting the caller choose.

• Bottom line:

  • Use impl Trait to abstract over a concrete type you produce; use a generic only when the caller genuinely selects the return type.

  • If you need multiple possible concrete return types, neither works: use Box<dyn Trait>.

The turbofish ::<> is the syntax for supplying explicit type arguments to a generic function or method (e.g. parse::<i32>()). It is needed when the compiler cannot infer the generic type from the arguments or surrounding context.

• What it looks like: Written between the name and the call parens: function::<Type>(args) or value.method::<Type>().

• Why it's necessary:

  • Some generics have their type only in the return position, so arguments give the compiler nothing to infer from (e.g. "42".parse() could yield many types).

  • Writing x.collect::<Vec<_>>() tells the iterator which collection to build.

• Why the odd :: syntax: Plain foo<Bar>(x) is ambiguous in expression context: the parser can't tell < apart from a less-than comparison. The :: disambiguates it as type arguments.

• Alternative: annotate the binding instead: let n: i32 = "42".parse()?; works too: turbofish is just one way to give the type.

From and Into are the standard conversion traits: From<T> defines how to build a type from another, and Into<U> is the mirror that consumes a value to produce another. They are linked by a blanket impl, so you only implement From.

• From<T>: Defines fn from(value: T) -> Self: a value-consuming, infallible conversion.

• Into<U>: Defines fn into(self) -> U: same conversion, viewed from the source side.

• The blanket impl ties them together: The standard library provides impl<T, U> Into<U> for T where U: From<T>, so implementing From gives you Into for free. Never implement Into directly.

• When to use which: Implement From; use Into as a generic bound (fn f(x: impl Into<String>)) to accept anything convertible.

• Fallible variants: Use TryFrom/TryInto when conversion can fail; they return a Result.

The Eq/Ord pairs model equality and ordering, while PartialEq/PartialOrd model the weaker versions that hold when some values can't be compared. They are split so the type system can express things like floating-point NaN, which breaks the stricter laws.

• PartialEq vs Eq:

  • PartialEq gives == and != but allows that a == a may be false.

  • Eq adds the promise of reflexivity (every value equals itself); it has no extra methods, it's a marker of stronger guarantees.

• PartialOrd vs Ord:

  • PartialOrd gives <, >, etc. via partial_cmp returning Option<Ordering>: comparison may be undefined.

  • Ord guarantees a total order via cmp returning Ordering: every pair is comparable.

• Why floats motivate the split: f64 implements PartialEq/PartialOrd but not Eq/Ord, because NaN != NaN and NaN is unordered with everything.

• Practical impact: HashMap keys and sort() require Eq/Ord, so you can't sort a Vec<f64> without something like sort_by(partial_cmp).

Operators in Rust are syntactic sugar for trait methods: a + b calls a.add(b) from the Add trait, a * b calls Mul, and so on. You overload an operator by implementing its trait for your type.

• Each operator maps to a trait: std::ops defines them: Add, Sub, Mul, Div, Neg, Index, and += variants like AddAssign.

• Associated type Output: The trait has an Output type, so the result type can differ from the operands.

• Generic over RHS: Add<Rhs = Self> defaults the right-hand side to the same type but lets you support mixed-type operations (e.g. Vec2 * f64).

• Ownership note: add(self, rhs) takes operands by value; implement it for references too if you want &a + &b without moving.

• Coherence limit: The orphan rule means you can only implement these for types you own (or with your own trait), so no overloading purely foreign type pairs.

Lifetime elision is a set of compiler rules that let you omit lifetime annotations in common function signatures where the intent is unambiguous. The compiler applies three rules to assign lifetimes; if they fully determine every output lifetime, you don't have to write them, otherwise it errors and asks you to annotate.

• It's sugar, not inference: Elision only fills in annotations in signatures; the borrow checker still does the real work inside the body.

• The three rules:

  1. Each elided input reference gets its own distinct lifetime parameter.

  2. If there is exactly one input lifetime, it is assigned to all elided output lifetimes.

  3. If there are multiple inputs but one is &self or &mut self, the lifetime of self is assigned to all elided outputs.

• When elision fails: Two reference inputs and a reference output (no self): rules 2 and 3 don't apply, so you must annotate (e.g. the longest function).

Lifetimes are compile-time annotations that let the borrow checker prove every reference is valid for at least as long as it's used; if a reference could outlive the data it points to, the code is rejected before it ever runs.

• Lifetimes name relationships:

  • A lifetime like 'a represents a region of code for which a reference must remain valid.

  • The compiler requires the referent to outlive the reference's lifetime.

• The check:

  • If a function returns a reference, its lifetime must be tied to an input; you can't return a reference to a local that gets dropped.

  • Returning a borrow to data that goes out of scope fails to compile.

• Result: Dangling pointers are caught statically rather than producing undefined behavior at runtime.

The 'static lifetime means a reference is valid for the entire duration of the program, whereas a variable's scope is the lexical region in which a name is usable; they are related but distinct concepts.

• Scope of a variable:

  • A lexical/syntactic notion: where the binding is in effect, ending at the closing brace where it's dropped.

  • Governs when destructors run and when the name is accessible.

• 'static lifetime:

  • A constraint on how long referenced data lives: the whole program run.

  • String literals (&'static str) and static items have it naturally.

• Key difference: Scope is about a name's visibility; a lifetime is about how long the data behind a reference remains valid. A short-scoped variable can still hold a 'static reference.

Because push takes &mut self on the whole vector and may reallocate its backing buffer, any existing reference to an element could be left pointing at freed memory; the borrow checker forbids the mutable borrow while a shared borrow into the vector is still alive, regardless of which element it targets.

• Reallocation is the real danger: When capacity is exceeded, the vector allocates a new buffer and moves elements; every prior element reference becomes dangling.

• Borrows are per-value, not per-element:

  • A &vec[0] borrows the entire Vec, so push (which needs &mut Vec) conflicts with it.

  • The compiler can't generally know mutation is safe, so it conservatively rejects all aliasing-plus-mutation.

• This prevents iterator invalidation: A class of real C++ bugs (dangling pointers after a resize) is turned into a compile error.

A scope is a lexical region of source code where a binding is valid, while a lifetime is the span during which a reference's referent is guaranteed valid; lifetimes are inferred from (and constrained by) scopes but reasoned about by the borrow checker, not just braces.

• Scope:

  • Syntactic: determined by {} blocks; controls visibility and when a value is dropped.

  • A property of variables/bindings.

• Lifetime:

  • A property of references: the region over which a borrow must stay valid.

  • With NLL (non-lexical lifetimes), a lifetime can end before the enclosing scope does, at the reference's last use.

• Relationship: The referent must live for a scope that fully contains the borrow's lifetime, which is how dangling references are prevented.

'static is the longest lifetime, meaning data that can live for the entire program run; but as a bound it actually means "does not contain any non-'static references", so it does NOT always require the data to literally exist for the whole program.

• As a reference lifetime: &'static T is a reference valid for the program's whole duration (e.g. string literals, static items, leaked allocations).

• As a bound on owned types:

  • An owned value like String satisfies T: 'static because it borrows nothing; you can still drop it early.

  • It means "contains no borrowed data that could expire", not "lives forever".

• The common confusion: &'static (a reference) demands eternal data; T: 'static (a bound) merely forbids shorter-lived borrows inside T.

Both represent a value available later, but a Rust Future is lazy and pull-based (it runs only when polled by an executor), whereas a JavaScript Promise is eager and push-based (it starts executing the moment it is created).

• Eager vs lazy:

  • A Promise begins its work immediately; the result is computed regardless of whether you await it.

  • A Future does nothing until awaited or spawned: no executor, no progress.

• Who drives it:

  • JS has a built-in event loop in the runtime; you never choose one.

  • Rust has no built-in runtime: you pick an executor like tokio or async-std.

• Cancellation:

  • Dropping a Rust Future cancels it cleanly: it just stops being polled.

  • A Promise cannot be cancelled once started.

• Zero-cost abstraction: Rust futures compile to state machines with no heap allocation by default, unlike JS promises which always allocate.

Send and Sync are auto marker traits that describe thread-safety: Send means a type can be moved to another thread, and Sync means a reference &T can be shared across threads. The compiler derives them automatically based on a type's fields.

• Send: Ownership can be transferred to another thread safely (most types are Send; Rc<T> and raw pointers are not).

• Sync: Defined as: T: Sync iff &T: Send. It means concurrent shared access through references is safe.

• How the compiler decides:

  • They are auto traits: a struct is Send/Sync automatically if all its fields are. One non-Send field makes the whole type non-Send.

  • You normally never implement them by hand; doing so requires unsafe because you're asserting an invariant the compiler can't verify.

• Why it matters: APIs like thread::spawn require F: Send, so violations are caught at compile time rather than as runtime bugs.

A data race is when two or more threads access the same memory concurrently, at least one access is a write, and there is no synchronization, producing undefined behavior. Rust prevents this at compile time through its ownership and borrowing rules combined with the Send/Sync traits.

• The three ingredients of a data race: Shared access, concurrency, and at least one mutation, with no ordering between them.

• Aliasing XOR mutability: The borrow checker allows either many shared &T references or exactly one &mut T, never both. Without simultaneous aliasing and mutation, a race can't form.

• Send/Sync gatekeeping: To share data across threads it must be Sync; to move it, Send. Non-thread-safe types simply won't compile in threaded APIs.

• Safe shared mutation requires sync types: To mutate from multiple threads you must wrap in Mutex/RwLock/atomics, which provide interior mutability plus the synchronization the type system demands.

• Note: Rust prevents data races, not all race conditions (e.g. logical ordering bugs or deadlocks are still possible).

"Fearless concurrency" means the compiler statically rejects code that would cause data races, so concurrency bugs become compile errors instead of runtime crashes. It achieves this by reusing the same ownership system that guarantees memory safety, extended with the Send and Sync marker traits.

• Ownership and borrowing: The aliasing-XOR-mutability rule (one &mut or many &) removes the simultaneous shared-mutation that data races need.

• Send/Sync as thread-safety markers: Thread-spawning and channel APIs require these bounds, so non-thread-safe types are rejected at the boundary.

• Lifetimes: Prevent references from outliving the data they point to, so a thread can't hold a dangling reference to freed stack data; thread::scope or 'static bounds enforce this.

• Safe abstractions for sharing: Types like Arc, Mutex, and channels encode the synchronization rules in their types, so correct usage is the only thing that compiles.

• Net effect: You can refactor and parallelize aggressively: if it compiles, it's free of data races (logic bugs and deadlocks still need care).

They solve two different problems: Arc<T> provides thread-safe shared ownership (multiple threads can hold the same value), while Mutex<T> provides safe interior mutability (only one thread mutates at a time). The common pattern is Arc<Mutex<T>>.

• Arc<T> handles sharing:

  • An atomically reference-counted pointer; cloning it bumps the count so each thread owns a handle, and the data is dropped when the last handle goes away.

  • But Arc alone only gives shared &T access, which is immutable.

• Mutex<T> handles mutation:

  • Calling .lock() returns a MutexGuard giving exclusive &mut T access; the lock releases when the guard drops (RAII).

  • It is Sync when T: Send, turning a non-shareable type into one safe to access concurrently.

• Why both: A Mutex alone can't be shared by value across threads; Arc gives each thread an owner, and the Mutex inside serializes the writes.

Both are reference-counted smart pointers, but Rc<T> uses a plain non-atomic counter while Arc<T> uses an atomic one. Because Rc's count can be corrupted by concurrent updates, it is deliberately not Send (nor Sync), so the compiler forbids moving it across threads.

• Rc<T>: non-atomic counting:

  • Clone/drop do ordinary, non-synchronized increments/decrements: fast, but a data race if two threads do it at once, risking double-free or leaks.

  • It is explicitly marked !Send and !Sync, so thread::spawn won't accept it.

• Arc<T>: atomic counting: Uses atomic operations on the refcount, making clone/drop safe under concurrency, so it is Send + Sync (when T: Send + Sync).

• The tradeoff: Atomics cost more than plain integer ops, so Rc is the faster choice for single-threaded code, and Arc is the price of thread-safety. The compiler steers you to the right one automatically.

A Mutex gives a single exclusive lock for any access, while an RwLock distinguishes readers from writers, allowing many concurrent readers but only one writer. RwLock wins for read-heavy workloads, but its extra bookkeeping makes it slower and riskier under contention if writes are frequent.

• Mutex:

  • One lock for both reads and writes: simpler and cheaper per operation.

  • Best when access is brief, writes are common, or read/write ratio is balanced.

• RwLock:

  • Multiple .read() holders concurrently, or one exclusive .write().

  • Pays off when reads vastly outnumber writes and read sections are long enough that parallelism beats the higher locking overhead.

• Key tradeoffs:

  • Overhead: RwLock tracks reader counts plus writer state, so uncontended locking is more expensive than Mutex.

  • Writer starvation: depending on the implementation's fairness, a stream of readers can delay writers (or vice versa).

  • Both can deadlock; RwLock adds re-entrancy hazards (acquiring a read then a write on the same thread).

• Rule of thumb: Default to Mutex; reach for RwLock only when profiling shows a read-dominated hotspot, and consider atomics or sharding for extreme contention.

You spawn threads with std::thread::spawn and pass data either by moving ownership into the closure or by communicating through a channel created by std::sync::mpsc::channel(), which gives you a sender and a receiver to move values between threads safely.

• Moving data into a thread:

  • Use the move keyword so the closure takes ownership; the value is no longer accessible from the spawning thread.

  • Good for handing off ownership once, not for ongoing back-and-forth.

• Channels (mpsc) for message passing:

  • mpsc = multiple producer, single consumer: clone the Sender for many producers, one Receiver.

  • tx.send(value) moves the value across the channel; rx.recv() blocks until a value arrives (or all senders drop).

  • The receiver implements IntoIterator, so you can for v in rx to consume until the channel closes.

• Why it's safe: Ownership transfers with the message, so there is no shared mutable access and no data race: the type only needs Send.

• Channels vs shared state: "Share memory by communicating": prefer channels for handoff/pipelines; use Arc<Mutex<T>> when many threads must read/write the same data in place.

All three are smart pointers that put data on the heap, but they differ in ownership model: Box<T> is single ownership, Rc<T> is shared ownership within a single thread, and Arc<T> is shared ownership across threads with atomic reference counting.

• Box<T>: one owner:

  • Heap allocation with zero runtime overhead beyond the allocation; dropped when the owner goes out of scope.

  • Use for recursive types (Box<Node>), trait objects (Box<dyn Trait>), or moving large data to the heap.

• Rc<T>: shared, single-threaded:

  • Keeps a non-atomic reference count; clone() bumps the count, drop decrements, freed at zero.

  • Gives shared read-only access; combine with RefCell for mutation. Not Send, so single-thread only.

• Arc<T>: shared, thread-safe:

  • Same as Rc but the count uses atomic operations, so it's Send + Sync.

  • Pair with Mutex/RwLock for shared mutation across threads.

• How to choose:

  • Need one owner? Box. Multiple owners, one thread? Rc. Multiple owners across threads? Arc.

  • Prefer the cheapest that fits: atomics in Arc cost more than Rc's plain counter, so don't reach for Arc unless you actually cross threads.

Interior mutability is a pattern where a type lets you mutate the data it holds through a shared & reference, enforcing Rust's borrow rules at runtime instead of compile time. You choose RefCell<T> for single-threaded interior mutability and Mutex<T> when the data must be shared and mutated across threads.

• The core idea: Normally &T forbids mutation; interior mutability types use UnsafeCell internally to allow it while preserving aliasing rules another way.

• RefCell<T>: single-threaded:

  • Tracks borrows at runtime via borrow() and borrow_mut(); violating the rules panics rather than deadlocks.

  • Not Sync, so it cannot be shared across threads; no locking overhead.

• Mutex<T>: multi-threaded:

  • lock() blocks until exclusive access is granted, providing both interior mutability and thread synchronization.

  • Usually wrapped in Arc to share ownership across threads.

• Choosing:

  • Single thread (e.g. Rc<RefCell<T>> graph)? Use RefCell: cheaper and no lock.

  • Crossing threads? Use Mutex (or RwLock); RefCell won't even compile in that context.

Interior mutability lets you mutate data behind a shared & reference, with borrow rules checked at runtime. You choose RefCell<T> when you need to hand out references to the inner value (borrow it in place), and Cell<T> when you only need to copy values in and out wholesale.

• Cell<T>: move values in and out:

  • get() (for Copy types) and set()/replace() swap the whole value; you never get a reference to the interior.

  • No borrow tracking needed, so no runtime cost and it can never panic.

• RefCell<T>: borrow the interior:

  • borrow() and borrow_mut() return guards so you can read/mutate large or non-Copy data in place.

  • Enforces "many readers xor one writer" at runtime; breaking it panics.

• Choosing:

  • Small Copy value like a counter or flag? Cell.

  • Need to call methods on or hold a reference into the value (e.g. a Vec or struct)? RefCell.

  • Both are single-threaded only (not Sync).

Interior mutability is Rust's pattern for mutating data through a shared (&) reference, which the normal borrow checker forbids. It is built on UnsafeCell<T>, the one primitive that legitimately allows this, and the standard library wraps it in several safe abstractions.

• The foundation: UnsafeCell<T>: the only legal way to get a &mut T from a &T; every other type below is built on it.

• Single-threaded types:

  • Cell<T>: move values in/out, no references to interior, never panics.

  • RefCell<T>: runtime-checked borrows via borrow()/borrow_mut(), panics on violation.

• Thread-safe types:

  • Mutex<T> and RwLock<T>: interior mutability plus synchronization across threads.

  • Atomics (AtomicUsize, AtomicBool, ...): lock-free interior mutability for primitives.

• Why it exists: Enables patterns the static checker can't prove safe: shared graphs (Rc<RefCell<T>>), memoization/caching, and shared counters.

RefCell<T> works because Rust's immutability rule (&T means no mutation) is enforced statically, but RefCell moves that enforcement to runtime. Internally it stores its data in an UnsafeCell, which is allowed to produce a &mut T from a &self, and it tracks active borrows in a counter so the aliasing rules are still upheld.

• "Immutable" is about the reference, not the data: borrow_mut() takes &self, not &mut self, so you can call it through a shared reference.

• The runtime borrow flag:

  • It keeps a count of outstanding borrows: shared borrows increment it, a mutable borrow marks it exclusive.

  • borrow() returns a Ref guard, borrow_mut() a RefMut; dropping the guard restores the count.

  • Requesting a conflicting borrow panics at runtime, preserving "many readers xor one writer."

• The trade-off: You gain flexibility the compiler couldn't grant statically, at the cost of a small runtime check and the risk of a panic instead of a compile error.

Both Rc<T> and Arc<T> are reference-counted smart pointers giving multiple owners of the same heap data; the difference is that Arc uses atomic operations for its count so it is safe to share across threads, while Rc uses a faster non-atomic count and is single-threaded only.

• Rc<T> (Reference Counted):

  • Plain integer counter, cheap to clone and drop.

  • Not Send or Sync, so the compiler rejects it across threads.

• Arc<T> (Atomically Reference Counted):

  • Count updates use atomic instructions, which prevents data races on the counter itself.

  • Is Send + Sync (when T is), so it can be moved/shared between threads.

• The overhead:

  • Atomic increments/decrements are slower than ordinary ones and can cause cache contention under heavy cloning.

  • Note: Arc only makes the count thread-safe, not the data: for shared mutation wrap it as Arc<Mutex<T>>.

• When the overhead is worth it:

  • Only when data genuinely outlives a single thread or is shared by several: then Arc is the correct (and required) choice.

  • If everything stays on one thread, use Rc: the borrow checker will tell you if you actually need Arc.

A Weak<T> is a non-owning reference to an Rc<T> or Arc<T> allocation: it does not contribute to the strong count, so it doesn't keep the value alive, which breaks the ownership cycles that would otherwise leak memory.

• Strong vs weak counts: The value is dropped when the strong count hits 0, even if weak references remain; the allocation itself lingers until weak count also reaches 0.

• Why cycles leak: If two Rc nodes point at each other with strong references, each keeps the other's count above 0, so neither is ever freed.

• The fix: Make one direction weak (e.g. parent owns child via Rc, child points back to parent via Weak).

• Accessing the value: Call upgrade(), which returns Option<Rc<T>>: Some if still alive, None if dropped, forcing you to handle the dangling case safely.

• Created from a strong ref: Rc::downgrade(&rc) produces the Weak.

Unsafe Rust is a subset of the language, entered via the unsafe keyword, where you take responsibility for upholding memory-safety invariants the compiler can no longer verify. It unlocks exactly five extra capabilities (the rest of Rust's rules still apply).

1. Dereference a raw pointer (*const T or *mut T).

2. Call an unsafe function or method (including FFI / extern functions).

3. Access or modify a mutable static variable (global mutable state, which is inherently racy).

4. Implement an unsafe trait (e.g. Send / Sync manually).

5. Access fields of a union.

6. Key point: unsafe is not a license to do anything; it's a promise that you manually uphold the invariants for these five operations.

No, unsafe does not turn off the borrow checker or the type system: it only enables the five extra operations. All of Rust's ordinary ownership, borrowing, lifetime, and type rules continue to be enforced inside an unsafe block.

• Still enforced: Borrow checking on references (&T / &mut T), lifetimes, move semantics, and type checking all remain active.

• What changes: The compiler stops checking the safety of the five privileged operations and trusts you instead (raw pointers, for instance, are not borrow-checked).

• Your obligation: You must manually guarantee no data races, no dangling pointers, no aliasing violations, and valid memory: breaking these is undefined behavior.

• Best practice: Keep unsafe blocks small and wrap them in a safe API whose invariants you can reason about and test.

Rust makes errors part of the type system: a fallible function returns Result<T, E>, so the possibility of failure is visible in the signature and the compiler forces you to handle it, rather than errors flowing invisibly up the stack as exceptions.

• Errors as values: A function says it can fail via its return type; callers can't accidentally ignore it (warnings on unused Result).

• No invisible control flow: There's no hidden try/catch stack unwinding for normal errors; the ? operator makes propagation explicit but concise.

• Two categories, deliberately split: Recoverable errors use Result; unrecoverable bugs use panic! (the rough analog of an exception, meant for invariant violations).

• Tradeoffs:

  • Pro: predictability and exhaustive handling; you can see exactly where errors arise.

  • Con: more verbosity, eased by ? and crates like thiserror/anyhow.

The ? operator unwraps a Result/Option on success and early-returns the error on failure; for Result it also automatically converts the error into the function's declared error type via the From trait.

• Basic behavior: expr? yields the inner value on Ok/Some, and returns Err(e)/None from the enclosing function otherwise.

• The error conversion:

  • On an Err(e), ? applies From::from(e) to turn e into the function's error type before returning.

  • So if your function returns Result<T, MyError> and you have impl From<io::Error> for MyError, an io::Error propagates seamlessly.

• Why it matters:

  • Lets you combine many different error sources under one unified error type without manual match boilerplate.

  • Crates like thiserror generate these From impls for you; anyhow uses a catch-all error type.

The std::error::Error trait is the standard interface for error types: it lets different errors be handled uniformly (e.g. as Box<dyn Error>). A custom error is just a type (usually an enum or struct) that implements Display, Debug, and Error.

• What the trait provides:

  • A common supertrait bound (Error: Debug + Display) so callers can print and chain errors.

  • An optional source() method to expose the underlying cause for error chains.

• Steps to build a custom error:

  1. Define an enum/struct and derive Debug.

  2. Implement Display for human-readable messages.

  3. Implement Error (the default methods often suffice).

• Ergonomic shortcuts:

  • Implement From for source errors so the ? operator auto-converts them.

  • Crates like thiserror derive all of this; anyhow is handy for application-level errors.

In Rust, a move copies only the stack handle and invalidates the original, a shallow copy would duplicate the handle but leave both valid (which Rust forbids for owning types to avoid double-frees), and a deep copy duplicates the heap data too (done via clone()).

• Move:

  • Copies the pointer/len/cap, then invalidates the source so only one owner remains.

  • No heap allocation; cheap and the default for non-Copy types.

• Shallow copy:

  • Both bindings point to the same heap data and both stay valid.

  • Rust disallows this for owning types, since both would try to free the buffer (double-free).

• Deep copy:

  • Allocates a new heap buffer and copies the contents, giving fully independent values.

  • Explicit via .clone(); can be expensive.

• Note on Copy types: For stack-only Copy types there's no heap, so the bitwise copy is effectively a safe shallow copy with both valid.

The orphan rule says you can implement a trait for a type only if either the trait or the type is defined in your crate. It prevents conflicting trait implementations across crates and keeps coherence guaranteed.

• What it allows:

  • Your trait on any type, or any trait on your type.

  • Forbidden: a foreign trait on a foreign type (e.g. impl Display for Vec<T>).

• Why it exists (coherence):

  • Guarantees there is exactly one implementation of a trait for a type across the whole program.

  • Without it, two crates could each define conflicting impls, and linking them would be ambiguous and break.

• How to work around it: Use the newtype pattern: wrap the foreign type in a local struct, then implement the trait on the wrapper.

When a value goes out of scope, Rust runs its destructor: first the type's own Drop::drop (if implemented), then it recursively drops each field. Locals in a scope drop in reverse declaration order, and a struct's fields drop in declaration order.

• Order of dropping:

  1. Local variables drop in reverse order of declaration (last declared, first dropped).

  2. Tuple/struct fields drop in declaration order; Vec elements drop by index order.

• Nested structs drop top-down:

  • The outer type's drop body runs first, then each field is dropped, which recursively triggers each field's own destructor.

  • This is automatic: the compiler synthesizes "drop glue" even for types without a manual Drop impl.

• Moved-out values aren't dropped twice: Rust tracks moves (sometimes via a runtime "drop flag") so a value that was moved out is not dropped again at scope end.

• Types without resources: Plain Copy/POD types have trivial drop glue (no-op); only types owning resources (heap, files) do real work.

The Drop trait lets a type run cleanup code when it goes out of scope (free memory, close files, release locks). You cannot call .drop() directly, but you can force early destruction with the free function std::mem::drop.

• Purpose of Drop:

  • Provides deterministic, RAII-style cleanup tied to scope exit, with no garbage collector.

  • Implement fn drop(&mut self); it takes &mut self, not ownership, so you can't move fields out in it.

• Why you can't call value.drop(): It would leave the value initialized yet "already dropped," then drop again at scope end (double free). The compiler forbids the explicit call.

• Use std::mem::drop(value):

  • It takes the value by value (move), so ownership ends and the destructor runs immediately, then the value is gone from scope.

  • Common for releasing a MutexGuard early.

They differ in how they borrow the collection and what each yielded item is: iter() yields shared references, iter_mut() yields mutable references, and into_iter() consumes the collection and yields owned values.

• iter(): Borrows &self; items are &T. Read-only; collection still usable afterward.

• iter_mut(): Borrows &mut self; items are &mut T. Lets you mutate elements in place.

• into_iter(): Takes self by value; items are T (moved out). The collection is consumed.

• What a for loop picks:

  • for x in &v uses iter(), for x in &mut v uses iter_mut(), and for x in v uses into_iter().

  • Note: for references, (&v).into_iter() yields &T, which is why for x in &v works.

The three traits describe how a closure uses its captured environment: FnOnce can be called once (consumes captures), FnMut can be called repeatedly and mutates captures, and Fn can be called repeatedly with only shared access. The compiler picks the most permissive one automatically based on what the body does.

• They form a hierarchy: Every Fn is also FnMut, and every FnMut is also FnOnce. So Fn is the most capable, FnOnce the least.

• What each requires of the call:

  • FnOnce: takes self; calling it may move out captured values, so only once.

  • FnMut: takes &mut self; mutates its environment between calls.

  • Fn: takes &self; only reads captures, callable concurrently.

• How the compiler decides:

  • It inspects the body: if it only reads captures, it implements Fn (plus the others); if it mutates a capture, FnMut; if it moves a captured value out, only FnOnce.

  • Capture mode (by ref vs by value) is separate from which trait is implemented; move changes how things are captured, not directly which trait it satisfies.

move forces a closure to capture its environment by value (taking ownership) instead of by reference. It's necessary when the closure must outlive the scope that owns the captured variables, typically when spawning threads or returning closures.

• Default capture vs move:

  • Without move, the compiler borrows captures as narrowly as possible (by & or &mut).

  • With move, each captured variable is moved (or copied, if Copy) into the closure.

• When it's necessary:

  • Threads: thread::spawn requires 'static, so the closure can't borrow locals; move transfers ownership in.

  • Returning a closure from a function: it can't borrow the function's locals after they're gone.

  • Async tasks and callbacks that outlive the current scope.

• It's orthogonal to Fn/FnMut/FnOnce: move only changes how variables are captured; the call trait still depends on how the body uses them.

Iterators are lazy because adapters like map and filter just build a new iterator struct describing the work; nothing actually runs until a consumer drives the iteration. Adapters transform and return iterators; consumers (consuming adapters) pull values and produce a final result.

• Why lazy:

  • Each adapter wraps the previous iterator and returns a new type; no element is touched until something calls next().

  • This enables zero-cost chaining and even infinite iterators ((0..).map(...)) that you cut short.

• Iterator adapters: Take an iterator, return another iterator: map, filter, take, enumerate. Lazy by nature.

• Consumers:

  • Drive the chain to completion and produce a value: collect, sum, for_each, fold, count.

  • Internally they repeatedly call next() until it returns None.

• Practical consequence: A chain of adapters with no consumer does nothing; the compiler even warns about an unused iterator.