A pair of Rust kernel modules

mem::forget was the original variant of this, and it was stabilized as safe pre-1.0 https://doc.rust-lang.org/std/mem/fn.forget.html . It was originally marked as unsafe (in earlier pre-1.0 releases), but when it was realized that safety invariants couldn't depend on destructors being guaranteed to run, it was changed to be marked as safe in order to make that point more clear.

Box::leak is just a newer variant that provides a nicer API, allowing you to extract a reference to the leaked value at the same time.

It was always known that it was possible to leak memory by forming a reference counted pointer cycle, but it was fairly late in the pre-1.0 process that folks realized the interaction between this fact, and some proposed APIs that required blocking in a destructor in order to keep a stack frame alive, were incompatible. There was a long and reasoned discussion about it, and the Rust team decided that because it's not possible to categorically prevent resource exhaustion in a Turing complete language, that it was better to have the rules for what could be done in safe code include leaking memory (or otherwise failing to run destructors), and then code that provides safe abstractions has to keep that in mind, so you couldn't rely on blocking in a destructor to keep a stack frame alive.

It took some time in the development of Rust to figure out what the rules should be for what is marked as "safe" vs "unsafe"; you might imagine that any kind of undesirable behavior, like memory leaks, should be considered unsafe. But the distinction that the Rust project ended up on, and I think is the right decision, is that unsafe is only required for operations which could lead to undefined behavior. Rust provides tools to help prevent other kinds of undesirable behavior, like destructors that free memory for you when exiting a stack frame, but it won't refuse to compile code in which you set up a reference cycle and thus leak memory, as the behavior in that case is perfectly well defined, you just use more resources and may eventually run out.

Does this make sense to you? I feel like you are implying that there has been some massive rug-pull about what safety guarantees Rust provides, while Rust never guaranteed freedom from resource exhaustion, and during the run-up to 1.0 there was some learning about exactly the kind of guarantees you could make about when destructors were run, and some updates to the understanding of what unsafe code could rely on based on that and some engineering tradeoffs. If I'm misunderstanding your implication, or not explaining this clearly enough, let me know!