> I don’t see why it would be an either/or. For instance, Rc does not leak memory, and neither do many cases of interior mutability.
`Rc` and internal mutability together do allow creating cycles and thus leaking with only safe code. I suggest you to read https://cglab.ca/~abeinges/blah/everyone-poops/ if you haven't done already, it explains the historical reasons for why `std::mem::forget` was changed to be safe.
> Edit 2: maybe an auto trait could statically disallow Rc cycles somehow?
It could be done with an auto and implied trait that is implemented in the opposite case (the type can be safely leaked), but then all the ecosystem must be changed to use `?Leakable` and it would be a pain.
What about the other way? There could be a trait that means “references have the same escape semantics as a stack frame”, perhaps called NotLeaky, and then a variant of tokio spawn could require NotLeaky, and return a non-‘static future. NotLeaky could be inferred in the same way as Send and Sync.
As a bonus, high-availability systems could require NotLeaky at the top of their event loop, precluding runtime memory leaks.
Edit: that wouldn’t work, since the future could be leaked by the caller… will read that reference.
This won't work because there's nothing forcing you to pass `NotLeak` types to APIs that respect them. In other words, implementing a trait can only add capabilities to a type, not restrict it.
`Rc` and internal mutability together do allow creating cycles and thus leaking with only safe code. I suggest you to read https://cglab.ca/~abeinges/blah/everyone-poops/ if you haven't done already, it explains the historical reasons for why `std::mem::forget` was changed to be safe.
> Edit 2: maybe an auto trait could statically disallow Rc cycles somehow?
It could be done with an auto and implied trait that is implemented in the opposite case (the type can be safely leaked), but then all the ecosystem must be changed to use `?Leakable` and it would be a pain.