30 — Design Patterns

Answer: A — a separate builder struct with chained methods and a final validating build()

Explanation: The builder pattern exists in Rust largely because the language has no named/default function arguments — chained .method(...) calls on a dedicated builder struct simulate that ergonomics while letting each step be independently optional, and build() gives a single place to validate combinations and return Result for invalid configurations. Direct public-field mutation skips validation and locks in field names/types as public API forever. A positional-argument macro reintroduces the exact problem builders solve (unreadable call sites, fragile argument order). A trait-only approach without a separate accumulating struct doesn't match how the pattern is idiomatically structured in the ecosystem (e.g. reqwest::RequestBuilder, std::process::Command).

Answer: A — creates a distinct compile-time type so same-representation values with different meanings can't be mixed up accidentally

Explanation: Safety: Meters(f64) and Feet(f64) share an identical runtime layout (a single f64, and with #[repr(transparent)] even guaranteed ABI-identical to f64) but are different types to the compiler — passing a Feet where Meters is expected is a compile error, catching unit-confusion bugs (the kind that famously destroyed the Mars Climate Orbiter) at compile time instead of production. It has zero effect on runtime memory representation/precision — the wrapper is typically free at runtime (a compile-time-only distinction). It's a voluntary pattern, not a compiler requirement for single-field structs (plenty of single-field structs aren't newtypes in this sense). And trait impls like Add/Sub are never automatic — they must be explicitly implemented (or derived, where applicable) for the new type; wrapping a value implements nothing by itself.

Answer: A — wrap the foreign type locally so the impl target (the wrapper) is local, satisfying the orphan rule for the foreign trait

Explanation: Idiom: The orphan rule blocks impl Display for Vec<String> directly because neither Display nor Vec is defined in your crate — both are foreign. Wrapping Vec<String> in a local tuple struct Wrapper makes the impl target local, satisfying "at least one of trait or type must be local," even though the trait itself remains foreign. Implementing a local trait on a local type was never blocked by the orphan rule in the first place (that's always allowed), so option B describes a non-problem. Newtype has nothing to do with borrow-checker aliasing rules — those are governed by &/&mut reference rules, unrelated to type wrapping. And Display is subject to the orphan rule exactly like any other foreign trait; there's no special exemption.

Answer: A — states become distinct types, so only valid-for-that-state methods exist, and invalid transitions fail to compile

Explanation: Safety: In the typestate pattern, Door<Locked> and Door<Unlocked> are different types with non-overlapping method sets (unlock only exists on Door<Locked>, open only on Door<Unlocked>), so attempting Door<Locked>::open() is a "no method named open found" compile error — the illegal transition is caught before the program ever runs, unlike the described enum-plus-runtime-match approach (option B), which is a valid but strictly weaker pattern (it moves the same check to runtime, where a forgotten branch panics or misbehaves in production instead of failing the build). It's related to but distinct from a general state machine (which typestate implements specifically via the type system, not just any state-tracking technique), and it requires no unsafe — transitions are ordinary by-value moves consuming the old-state value and returning a new-state value.

Answer: A — drop() runs automatically at scope exit through normal flow, early return, or unwinding, with only mem::forget/abort as exceptions

Explanation: Safety: Rust has deterministic, scope-based destruction (no garbage collector) — the compiler inserts a call to drop() at every point a value's owning scope ends, including early returns and (during unwinding, not panic = "abort" builds) stack unwinding from a panic, which is what makes RAII reliable for releasing locks, closing files, and flushing buffers even in error paths. The two real escape hatches are std::mem::forget (explicitly suppresses the drop) and process abort/SIGKILL (no unwinding happens at all). It is not tied to main returning Ok, is very much automatic (that's the entire point of RAII — no explicit .close() call needed, unlike C's manual fclose), and has nothing to do with garbage collection or Java's notoriously non-deterministic, sometimes-never-called finalize() — Rust's timing is fully deterministic and scope-derived.

Answer: A — an exhaustive match, with the compiler enforcing every variant is handled

Explanation: Idiom: Rust's enums plus exhaustive match give you the visitor pattern's core benefit (dispatch based on concrete node kind) without needing the classic double-dispatch machinery OOP languages use to work around lacking sum types — and critically, adding a new Expr variant makes every non-wildcard match across the codebase a compile error until updated, which is a stronger guarantee than the classic visitor pattern's Visitor trait (where forgetting to implement a new visit method for a new node type is usually just a silent no-op or an easy-to-miss default). A separate Visitor trait is a valid alternative implementation style (useful when the set of "visitors"/operations grows faster than the set of node types), not a requirement — enums alone are sufficient and commonly used exactly this way (e.g. rustc's own AST handling). dyn Any downcasting throws away compile-time exhaustiveness checking entirely and is not idiomatic here.

Answer: A — when operations grow faster than node types, trait-based visitors avoid editing every existing match

Explanation: Idiom: This is the classic "expression problem" trade-off: enum + match makes adding a new node type force-update every match site (good when types are the axis of change, as in Q6), while trait-based visitor makes adding a new operation (a new impl Visitor) require zero changes to existing code, at the cost of adding a new node type now requiring updates across every existing Visitor implementor. Neither is "strictly superior" — the right choice depends on which axis (types vs. operations) changes more often in that codebase. There's no inherent, universal runtime performance advantage to virtual dispatch over a match (a match on a fieldless discriminant is typically a fast jump table, often faster than a vtable call), and enums recurse over trees perfectly well via Box/Rc indirection, as shown in Q6's Expr — recursion is not a limitation of the enum approach.

Answer: A — build() returns Err(BuildError::MissingApiKey), the idiomatic way to surface a missing required field

Explanation: Using .ok_or(...)? converts the Option<String> into a Result, propagating a descriptive error rather than panicking — this is exactly why build() idiomatically returns Result<Config, BuildError> instead of Config directly, letting callers handle missing-configuration errors gracefully (e.g. surfacing a helpful message) instead of crashing. It does not panic (there's no .unwrap() anywhere in this path), does not silently default a security-sensitive field like an API key to empty string (that would be a dangerous silent failure mode, not idiomatic error handling), and Option<String> inside a plain struct is completely ordinary, valid Rust with no compile issue.

Answer: A — compile error; unlock(self) moves door, so the second call is a use-after-move

Explanation: Safety: This is precisely why typestate methods take self by value rather than &self/&mut self — consuming self guarantees the old-state value cannot be reused after transitioning, which is what makes a state transition genuinely one-way and irreversible at compile time (you can't accidentally "unlock an already-consumed door twice"). The borrow checker rejects the second door.unlock(...) at compile time with a "use of moved value" error — this is a compile-time diagnostic, never a runtime panic, since move-checking has no runtime component. Structs are never implicitly Copy by default in Rust (it must be explicitly derived and is only valid when every field is Copy), and even a zero-sized PhantomData-only struct doesn't get free Copy without #[derive(Copy, Clone)] explicitly opting in.

Answer: A — the process aborts immediately; Rust cannot unwind through two simultaneous panics

Explanation: Safety/Debug: If a drop() runs as part of unwinding from an earlier panic and itself panics, Rust has no defined way to unwind two panics at once through the same stack, so the runtime immediately calls abort() — no further cleanup, no graceful shutdown, process terminates hard. This is a production-relevant gotcha: Drop implementations should avoid any code that can panic (avoid .unwrap(), indexing, arithmetic that can overflow in debug mode, etc.), preferring to log-and-continue or use fallible alternatives, precisely because a panicking destructor during unwinding is one of the few ways to lose the ability to gracefully report an error at all. The compiler does not reject panic! inside drop() — it's syntactically and semantically legal, just dangerous in this specific double-unwind scenario; the double-panic-aborts behavior is a hard runtime rule, not something silently absorbed or overwritten.

Answer: A — leaving the inner field public lets callers construct the newtype directly, bypassing validation

Explanation: Safety: The entire value of a "validated newtype" (non-empty buffer, positive integer, normalized email, etc.) depends on there being no way to construct one except through the checked constructor — if the tuple field is pub, anyone can write NonEmptyBuffer(vec![]) directly from outside the module, completely bypassing new()'s emptiness check and silently reintroducing the exact bug the type was created to prevent. Keeping the field private (as shown, no pub on Vec<u8>) is what makes new() the only construction path. Option vs Result in the constructor is a legitimate, context-dependent API choice (not "always wrong" — Option is fine when there's only one failure reason and no extra context to convey). Deriving Clone is harmless here — cloning a valid NonEmptyBuffer produces another valid one, since the invariant (non-empty) is preserved by copying the same data. Constructor naming is a style preference with no soundness implication.

Answer: A — compile error; build(self) moves the builder, so calling it twice is a use-after-move caught at compile time

Explanation: Idiom: Taking self by value in build() is a deliberate design choice (not an accident) — it statically enforces "a builder can only be finalized once," turning a whole class of "did I already call .build()?" bugs into compile errors rather than needing runtime tracking. This is why many builder APIs use self (consuming) rather than &mut self for chained methods that lead into build(): it composes with move semantics to make double-finalization structurally impossible, exactly analogous to the typestate consumption in Q9. There's no runtime panic path here — the compiler rejects the second call before the program can ever run, and there's no default-empty fallback or implicit duplication; if a caller genuinely needs to build multiple times, the builder type would need to implement Clone explicitly, or expose build(&self) instead (a valid alternative design with its own trade-offs, but not what's shown here).

Answer: A — compile error; Copy and Drop are mutually exclusive by design

Explanation: Safety: Copy means assignment/passing duplicates the bits with no move semantics — both the "original" and the "copy" remain simultaneously valid and usable. Drop is built entirely around Rust's ownership guarantee that a value has exactly one owner responsible for cleanup at scope end. If a type were both, you'd get either a double-free (both bitwise copies' destructors trying to free/release the same resource) or an ill-defined "which copy actually owns the resource" question — so the compiler flatly rejects #[derive(Copy)] (or a manual impl Copy) on any type that also impl Drop, regardless of whether the drop() body is empty (option D is a red herring: the restriction is structural/type-level, not based on the body's contents). This isn't silently downgraded to Clone-only either — it's a hard compile error at the derive/impl site.

Answer: A — return a Result (or equivalent) whose Ok/Err carry the two possible resulting typestates

Explanation: Idiom: Fallible transitions compose naturally with typestate by making the return type itself encode "one of these two states is what you'll get," typically via Result<Connection<Connected>, Connection<Disconnected>> or a small enum — the caller is then compiler-forced (via match/?) to handle both branches, and whichever branch executes hands back a correctly-typed value for that actual state, preserving the whole pattern's compile-time guarantees through the fallible step. Typestate absolutely can express fallible transitions this way — panicking would be a strictly worse design that throws away the ability to recover from an ordinary, expected failure (a network connect timing out is not exceptional). Returning Connection<Connecting> unchanged doesn't reflect reality (the state actually changed to failed/disconnected) and invites infinite-retry bugs. Using transmute to force a type back is exactly the kind of unsound hack the entire pattern exists to make unnecessary — legitimate typestate code should never need unsafe to move between states.

Answer: A — use ..Default::default() for simple public-field configs with no validation; use a builder when validation, derived defaults, or required-field enforcement is needed

Explanation: Idiom: ..Default::default() is lighter-weight and perfectly idiomatic when a struct's fields are all meant to be public and independently valid in any combination — it avoids the ceremony of a whole separate builder type for something trivial. A builder earns its complexity when construction has invariants to check (cross-field validation), needs a required field enforced (impossible to skip api_key, unlike a Default-based struct literal where every field is implicitly optional-with-a-default), or benefits from a readable fluent chain for many optional settings. "Always use a builder" ignores this real trade-off and adds needless boilerplate for simple cases. The syntax shown (Config { timeout: 30, ..Default::default() }) is exactly the valid, common combination of named fields plus a base — the claim that they can't be combined is false. And builders remain a first-class, actively-used pattern in modern Rust (e.g. std::process::Command, reqwest::ClientBuilder) — they were never edition-specific or made obsolete by Default.

Answer: A — take mut self by value, return Self; supports both chaining and imperative reassignment

Explanation: Idiom: Taking self by value (not &mut self) and returning Self is the standard consuming-builder signature: it supports fluent chaining (RequestBuilder::new(url).header(...).header(...).build()) because each call produces a new owned value to call the next method on, and it equally supports the imperative style let b = b.header(...); since it's just an ordinary function taking and returning a value — no special calling convention required. &mut self -> () cannot be chained at all (there's nothing returned to call the next method on — you'd need separate statements), so it's actually the opposite of what enables chaining, making that option's claim backwards. &self returning a freshly allocated builder is unnecessary allocation churn for no benefit over consuming-and-returning the existing owned value, and it isn't "more performant" — it's strictly more allocation for the same result. Supporting both styles with one signature is exactly what the consuming pattern already does, contrary to the last option.