Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
std::mem::forget(value) consumes value and skips its destructor; it does not itself free heap memory. If the value owns a Vec, String, Box, or another resource whose destructor would release memory or close a resource, that cleanup does not happen. Whether heap memory is leaked depends on what the value owns.
What happens when you call std::mem::forget?
Rust normally runs a value’s destructor when the value is dropped, including when its binding leaves scope. A destructor can release a heap allocation or close an operating-system resource. std::mem::forget takes ownership of the value and prevents that destructor from running, so ordinary scope cleanup will not later destroy that value.
For example:
let data = vec![1, 2, 3];
std::mem::forget(data);The vector is consumed by the call. Its destructor does not run, so the vector does not release its backing heap allocation. This is an illustration of the effect for a Vec, not a claim that every value passed to forget owns heap memory.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Does it always leak heap memory?
No. forget suppresses destruction; it is not an allocator operation. The result depends on the value’s destructor. If dropping the value would free an allocation, the allocation can remain allocated. If the value does not own such an allocation, there may be no heap memory to leak.
#1 Best Overall
The same distinction applies to non-memory resources. The Rust core documentation gives a File example: forgetting it prevents its destructor from closing the file descriptor. That can be appropriate when ownership of the descriptor has been transferred to code outside Rust, but it is not a general resource-management technique.
Is mem::forget unsafe or undefined behavior?
Calling std::mem::forget is safe Rust and is not, by itself, undefined behavior. The Rust core documentation explains: “forget is not marked as unsafe, because Rust’s safety guarantees do not include a guarantee that destructors will always run.”
Rank #2
The Rust Reference similarly says that unsafe code must not rely on a value being dropped unless the language guarantees it. Destructors can fail to run for reasons besides an explicit call to forget, including reference cycles or process::exit. As a result, unsafe abstractions must remain sound even if a caller does not drop a returned value.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallSafe does not mean desirable. A leak can retain memory or leave an external resource open, and either outcome may be a program correctness or resource-management problem. The Rustonomicon includes memory leaks among operations Rust considers safe while warning that they can still make a program incorrect.
Rank #3
When is ManuallyDrop a better fit?
For specialized ownership-transfer code, the standard library generally points to ManuallyDrop<T> rather than extracting raw parts and then calling forget. The wrapper prevents automatic destruction while leaving the value available for carefully managed operations.
| Question | std::mem::forget(value) |
ManuallyDrop<T> |
|---|---|---|
| Main effect | Consumes the value and skips its destructor. | Wraps a value to inhibit automatic destructor execution. |
| Common role | Suppress cleanup, including after ownership is transferred outside Rust. | Control destruction while retaining access to a value during a carefully managed operation. |
| Main hazard | Cleanup is skipped; using it for memory ownership transfer can be error-prone. | Manual destruction can cause unsoundness if already-dropped contents are exposed or dropped again. |
| Important detail | The value is consumed by the call. | It has the same layout and bit validity as T; it is not a wrapper for uninitialized memory. |
The sequencing matters in unsafe transfer code. With ManuallyDrop, automatic destruction is disabled before raw parts are extracted. With forget, extraction must happen first and the value is consumed afterward; a panic in between can trigger an unwanted drop and, in an unsafe ownership-transfer pattern, risk a double-free. The ManuallyDrop pattern is designed so that this kind of failure errs toward a leak rather than a double-drop. These APIs are for specialized ownership control, not routine Rust code.
Quick Recap
Sources and further reading
- Rust core source documentation for
mem::forgetexplains its behavior, safety rationale, file-descriptor example, and comparison withManuallyDrop. - The Rust Reference on destructors describes destructor behavior and the limits on relying on drops.
- The standard library documentation for
ManuallyDropcovers the wrapper and its safety hazards. - The nightly
Vecdocumentation describes its heap allocation; it provides allocation context, not evidence of a change tomem::forget. - The Rustonomicon’s discussion of leaks explains why leaking can be safe yet undesirable.
- The Rustonomicon is an advanced guide for unsafe Rust; its front matter notes that the book is incomplete.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
