A deep dive into Rust's decision to permit memory leaks via reference-counted types (Rc/Arc) and the consequences for API design. The post examines a flaw in the scoped threads API — where Rc cycles could prevent thread join guards from running their destructors, causing unsafe memory access — and explains why the bug was in the API design, not Rust's type system. Two RFCs proposing to restrict Rc to prevent leaks (a Leak trait and a ScopedRc approach) are analyzed and ultimately rejected: both introduce a fundamental 'leakable vs non-leakable' type distinction that bubbles up through all APIs, harming composability far more than the lost RAII idiom is worth. The preferred fix is a closure-based scoped thread API that guarantees thread joining without relying on destructors.

26m read timeFrom smallcultfollowing.com
Post cover image
Table of contents
Section 1. The problem in a nutshellSection 2. What is the impact of leaks on the status quo?Section 3. Can we prevent (some) resource leaks?Section 4. Conclusion.