Rust APIs should name who reclaims transferred memory

A Rust API that plans to return memory to its allocator should express an ownership transfer from the start. Treating an allocation retained through leak as a temporary loan leaves the most important part of the contract hidden: who may reclaim it, and when every other user must stop. That uncertainty becomes maintenance work for the next person changing the interface.

This is a November 2026 retrospective on the week beginning September 30. The Rust 1.99 announcement, dated October 1, recommends ownership-transfer APIs instead of leaking and later reclaiming memory. It explicitly describes updated guidance without a change to language semantics. Existing code therefore needs a careful contract review; the announcement alone does not establish that every older use was undefined behavior.

Start with the final owner

Consider a hypothetical library that hands an allocation to another component until a completion callback arrives. The useful design question is which component owns the allocation during that interval. A reference explains how someone may access a value. An ownership transfer must also explain who is responsible for destruction and deallocation. Those responsibilities remain even when the ordinary Rust owner has been consumed.

For a boxed value, Box::into_raw consumes the box and returns a raw pointer. The allocation remains alive, but the automatic cleanup associated with that box no longer runs. The recipient must arrange cleanup under the relevant safety requirements. A raw pointer is not permission to dereference freely, to create overlapping mutable references, or to reconstruct several owners for the same allocation.

Reconstructing ownership with Box::from_raw requires a valid pointer to memory allocated by the global allocator, with the layout required by Box. The value must still be valid for its type. Two owning boxes must never coexist for the same allocation. Each raw ownership transfer may be reclaimed only once; letting the reconstructed box drop then performs destruction and deallocation. Every outstanding use must end before reclamation. A pointer retained elsewhere cannot continue to be used after the allocation has been freed.

Those conditions belong in the interface design. If a foreign component receives the pointer, the completion protocol must establish that it has stopped accessing the allocation. A callback named “finished” is insufficient if a background worker can still retain a pointer. If cancellation and completion can race, their agreement about the final owner matters as much as the normal path. These are design conditions for the hypothetical interface, not claims about a tested library.

A leak communicates a different lifetime

Box::leak consumes a box and yields a mutable reference whose lifetime is constrained by the value's type and the chosen lifetime. It prevents the box's usual automatic destruction. A 'static reference is possible when the type permits it; it does not make every contained reference valid forever. Designing later reclamation around such a reference requires reasoning about every place that reference, or access derived from it, might survive.

The October guidance recommends Box::into_raw or Box::into_non_null for planned reclamation. Its significance for maintainers is the declared intent. Someone reviewing the boundary can look for the matching ownership return, rather than discovering an informal promise to undo a leak. Choosing the clearer operation still leaves the pointer and cleanup requirements to be satisfied. The name of an API cannot prove a concurrent protocol correct.

A practical review should follow each allocation through successful completion, early rejection and cancellation. If ownership never leaves the caller after rejection, the caller retains cleanup responsibility. If ownership has already passed, cleanup must follow the receiving side's agreed protocol. Writing down that distinction can expose a missing acknowledgement or a path with two would-be owners before a future refactor makes the ambiguity harder to find.

The strongest case for keeping a leak

A bounded allocation deliberately retained for the entire process can be reasonable. Configuration loaded once and used until exit is a different requirement from a buffer allocated for every request. If no in-process reclamation is planned, a leak can express the intended lifetime directly. That counterexample limits the recommendation: replacing every occurrence simply because the word “leak” appears would ignore the design.

The business distinction is frequency and responsibility. One bounded allocation may be an accepted operating cost. An allocation repeated as work arrives can grow with traffic if its return path is missing. Neither conclusion follows from syntax alone. Maintainers need to know whether the allocation is once per process, once per tenant or once per operation, and whether a future shutdown requirement changes that choice.

An earlier release addresses a separate operation. The Rust 1.98 announcement of August 20 discusses clarified guarantees around moving ManuallyDrop<Box<_>> after manual destruction, following a compiler fix. That does not establish a general permission to reclaim leaked references. Manual destruction of a wrapped value and transferring a live allocation through a pointer require their own reasoning; combining their headlines would erase the distinction.

Make reclamation reviewable

For an existing integration, begin with the written ownership contract and the paths that terminate access. Recommend a transfer API when return is planned, retain intentional process-lifetime allocation where justified, and require a separate safety argument for the implementation. No compiler run or unsafe experiment is needed to establish that these are different design choices.

That work fits software maintenance: recovering an interface's responsibilities before changing it. A useful maintenance deliverable names the current owner at every handover and the condition that permits final reclamation. The next engineer should be able to find that answer without reverse-engineering an agreement hidden behind a temporary leak.