History. ManuallyDrop<T> emerged in Rust 1.20 as a zero-cost wrapper explicitly designed to inhibit automatic destructor invocation, functioning as a safer and more semantically clear alternative to mem::forget when handling partially initialized data or implementing complex container types. Unlike MaybeUninit<T>, which manages memory that might not yet contain a valid instance of T, ManuallyDrop assumes the inner value is always fully initialized but defers its destruction timing to the programmer's discretion. This distinction proves crucial when implementing custom Drop traits for collection types, as ManuallyDrop allows field-wise extraction during destruction without triggering double-drop errors or requiring the runtime overhead of Option<T>.
Problem. Consider a scenario where a generic container must drain elements during its destruction cycle or recover from a panic during in-place construction; standard Drop implementations cannot move values out of self because the compiler will still attempt to drop the moved-from location after the Drop implementation completes. While Option<T> with take() offers a safe alternative, it introduces runtime overhead (the discriminant boolean) and requires T to be constructed initially as an Option, violating zero-cost abstraction principles. ManuallyDrop provides a compile-time guaranteed wrapper with identical memory layout to T itself, enabling direct field extraction via ptr::read without extra space allocation or branching penalties.
Solution. The wrapper disables the automatic invocation of T's destructor through its #[repr(transparent)] attribute, requiring explicit unsafe calls to ManuallyDrop::drop to run destructors. When implementing Drop for a struct containing heap-allocated resources, you wrap sensitive fields in ManuallyDrop, allowing extraction of the inner value followed by manual cleanup. Accessing the inner value after calling drop constitutes immediate undefined behavior, as the value becomes logically uninitialized despite remaining in memory, potentially containing dangling pointers if T owned heap memory. This pattern is essential for zero-cost abstractions like Vec::drop, which must deallocate the backing store while preventing element drops if extraction failed due to capacity overflows.
use std::mem::ManuallyDrop; use std::ptr; struct Buffer<T> { // Raw pointer to heap allocation ptr: *mut T, // ManuallyDrop allows us to take the Vec without auto-dropping temp_storage: ManuallyDrop<Vec<T>>, } impl<T> Drop for Buffer<T> { fn drop(&mut self) { // Safely extract the Vec from ManuallyDrop let vec = unsafe { ptr::read(&*self.temp_storage) }; // Manual drop required to prevent double-drop of Vec unsafe { ManuallyDrop::drop(&mut self.temp_storage) }; // Now we can use vec without the compiler trying to drop self.temp_storage again drop(vec); } }
Problem description. While developing a high-performance lock-free queue for an embedded Rust system running on a microcontroller with 128KB RAM, we encountered a critical issue during the queue's Drop implementation. The queue used an intrusive linked list where nodes contained Box<Node<T>> pointers, and we needed to drain the queue of 10,000+ nodes without recursing through standard Drop implementations (which would cause stack overflow in our constrained environment). Furthermore, some nodes might be in an intermediate initialization state during a concurrent push operation when a panic occurred, requiring us to selectively destroy only fully initialized nodes while leaking partially constructed ones to maintain safety.
Solution 1: Using Option and take. We initially wrapped each node pointer in Option<Box<Node<T>>> and used while let Some(node) = head.take() to drain the list. Pros: Completely safe, idiomatic Rust, no unsafe code required, and straightforward to maintain. Cons: Every node carried an extra byte for the Option discriminant, increasing memory footprint by roughly 12% in our embedded context, and the take() operation introduced a branch prediction penalty in the hot path that degraded throughput by 8% in benchmarks.
Solution 2: Using mem::forget. We considered using std::mem::forget on the entire queue structure to prevent automatic dropping, then manually freeing memory with alloc::dealloc. Pros: Prevented recursive drops and avoided Option overhead. Cons: Extremely unsafe, required manual memory management bypassing Rust's allocator safety checks, leaked memory if manual freeing failed, and made the code unmaintainable for future developers unfamiliar with raw pointer arithmetic.
Solution 3: ManuallyDrop fields. We redesigned the Node struct to store its next pointer as ManuallyDrop<Box<Node<T>>>. During Drop, we iterated through the list using raw pointer manipulation, extracted each Box via ptr::read, moved it to a local variable, and explicitly called ManuallyDrop::drop on the extracted slot only after verifying the node was fully initialized via an atomic status flag. Pros: Zero memory overhead (ManuallyDrop is #[repr(transparent)]), complete control over destruction order, ability to handle partially initialized nodes safely by skipping manual drop for uninitialized nodes. Cons: Required unsafe blocks and careful audit of invariants by senior engineers.
Which solution was chosen and why. We selected Solution 3 (ManuallyDrop) because the embedded system's strict RAM limitations made the Option overhead unacceptable for our 10,000 node capacity requirement, and mem::forget was too error-prone for production code. ManuallyDrop allowed us to maintain Rust's memory safety guarantees while providing the precise control needed for intrusive data structures. We wrapped the unsafe operations in a small, thoroughly tested module with debug_assertions verifying invariants in test builds, and documented the safety invariants extensively.
Result. The queue successfully handled maximum-capacity chains without stack overflow, maintained constant memory usage regardless of chain length, and passed Miri (Mid-level Intermediate Representation Interpreter) validation confirming absence of undefined behavior. The explicit manual drop calls made the destruction logic immediately visible to code reviewers, preventing subtle double-drop bugs that had plagued earlier C++ implementations of the same data structure in legacy codebases.
Question: Why must the inner value of ManuallyDrop<T> be considered logically inaccessible after invoking ManuallyDrop::drop, and why doesn't the Rust compiler enforce this restriction at compile time?
Answer. Once ManuallyDrop::drop is called, the inner value transitions to a logically uninitialized state, identical to MaybeUninit before initialization. The compiler cannot enforce this at compile time because ManuallyDrop is designed to be used in contexts like Drop implementations where the borrow checker already permits complex mutations of self through &mut self references. The wrapper intentionally retains its DerefMut implementation even after dropping to support certain atomic operation patterns, meaning the compiler has no built-in notion of "already dropped" at the type level. Accessing the inner value after dropping constitutes immediate undefined behavior because the destructor may have freed resources (like heap memory or file descriptors), leaving the wrapper containing dangling pointers or invalid bit patterns.
Question: How does ManuallyDrop affect the Send and Sync trait auto-implementation for the wrapped type T, and why is this crucial for concurrent data structures?
Answer. ManuallyDrop<T> carries the #[repr(transparent)] attribute, meaning it has identical memory layout and ABI to T, and it conditionally implements Send and Sync if and only if T implements them. Candidates often mistakenly believe that suppressing the destructor somehow weakens thread-safety guarantees or adds interior mutability like UnsafeCell. In reality, ManuallyDrop preserves all auto-trait implementations because it introduces no synchronization overhead or shared mutable state. This implies that sharing a &ManuallyDrop<T> across threads has identical safety requirements to sharing &T; the unsafety only emerges when you mutate the value or invoke manual drop, at which point standard ownership rules and exclusive mutable access requirements apply strictly.
Question: Why is using ptr::read to move out of a ManuallyDrop field safer than using ptr::read on a regular field during a Drop implementation, and what specific double-drop scenario does it prevent?
Answer. When you use ptr::read on a regular field, you create a bitwise copy of the value, but the original memory location remains "live" in the compiler's drop checker analysis. When the current Drop scope ends, the compiler automatically inserts destructor calls for all fields, including the one you just read from, causing a double-drop (use-after-free) when the copied value is also dropped at the end of its scope. By wrapping the field in ManuallyDrop, you signal to the compiler that this field should not be automatically destroyed when the parent struct drops. Therefore, after ptr::read, you can safely take ownership of the copied value without the compiler attempting to drop the source, because ManuallyDrop suppresses that automatic invocation, effectively acting as a "permission slip" to move out during Drop without violating the aliasing rules.