<div dir="ltr"><div><div><div><div><div>There has been a fair amount of discussion about RC here, but I think it is missing the bigger picture.<br><br></div>There are a lot of variation of RC that can be done, but it doesn't really matter. After all, the problem that we want to solve as languages designer here is to control how references escape.<br><br></div>This is mandatory to have safe RC. After all, reference counted objects will have member data, which aren't themselves reference counted, and the language have to ensure these do not escape in unsafe manner.<br><br></div>But here is the plot twist: if we can provide a language solution that ensure member data do not escape in unsafe manner, then we can ensure that whatever is in a RC wrapper doesn't escape in an uncontrolled manner. We win 2 things going that road:<br></div><div> - All variations of RC become a library problems. We don't need to make a judgement call on them at language level.<br></div><div> - Functionality and memory management can be decoupled (upcast problem, library can delegate RC/GC choice on their users).<br></div><div><br></div>Additionally, RC is a fairly small part of the problem. Unique reference require the same kind of escape analysis while being WAY more common than RC. Some here already did some grepping in Rust's source code to get an idea of this, but here are the number I get grepping into clang/llvm :<br>$ grep -r ../llvm/lib/ ../clang/lib/ -e unique_ptr | wc -l<br>    1362<br>$ grep -r ../llvm/lib/ ../clang/lib/ -e shared_ptr | wc -l<br>      73<br><br></div>It is not even close.<br></div>