> The (old) "Ownership You Can Count On" paper specifically says that the > elimination of reference counting with multi-threading is difficult and there > doesn't seem to be good proposed work around(s) that don't add greatly to the > complexity and only work when the threads are limited to not sharing memory > between them; is there newer work that overcomes that?
Again, you don't have to "optimize" them away. You can leave them turned on. Or you can switch them off as correct programs don't need them. > Other than as to this perceived limitation of RC in data cycles, how does B/D > support the extended development required to make it work as compared to RC? "perceived"? [https://medium.com/anysuggestion/preventing-memory-leaks-with-swift-compile-time-safety-49b845df4dc6](https://medium.com/anysuggestion/preventing-memory-leaks-with-swift-compile-time-safety-49b845df4dc6) [https://stablekernel.com/how-to-prevent-memory-leaks-in-swift-closures](https://stablekernel.com/how-to-prevent-memory-leaks-in-swift-closures)/ "This is why Swift always makes you add self. explicitly while in a closure to help prevent programmers from accidentally capturing self without realizing it, and therefore most likely causing a retain cycle." If I have to run leak detectors for my Rust/Swift programs anyway it's fair to say that RC is incomplete.
