If you disallow mutation of values in a collected context, then it Just Works. The only way to complete a cycle is by mutating a managed value or "tying the kno

If you disallow mutation of values in a collected context, then it Just Works. The only way to complete a cycle is by mutating a managed value or "tying the knot" via laziness (which is of course just mutation in a hat). Rust almost has this. Only shared (immutable) references can be obtained to values owned by a reference-counted pointer (which is nothing fancy -- just not implementing mutably dereferencing RCs). Since mutability is inherited, this freezes all reference counted data and everything it can reach. However Rust also provides types which specifically can be mutated in a shared context (a Mutex being the most obvious case), so you can indeed make reference-counted cycles and leak. Still, by default you can't leak. You have to opt into these "interior mutability" types. Basically, "shared XOR mutable" does not necessitate forbidding mutability universally. It just requires a way to freeze data when it is shared. You can even unfreeze it whenever you can prove it isn't actually shared (e.g. reference count = 1).