If you use enough Rc<RefCell<T>>, does rust become a garbage collected language?

[Lionelf329]

Thanks for the very thorough response! You made a lot of good points, it's probably easiest to follow if I go through them one by one in the same format.

@H2CO3

Reference counting can't detect cycles in itself. Merely adding Rc blindly all over the place would likely cause the code to leak.

Yep. Most code doesn't ever create reference cycles though, so I think it's an acceptable sacrifice to require the programmer to break cycles manually when these cases come up, like Swift does.

@H2CO3

it would now be a lot easier to accidentally keep a copy of the guard around, resulting in mysterious live-locks.

If I accidentally leaked the guard by making a cycle, then yeah. Otherwise, the single instance of the Rc<RefCell<MutexGuard<_>>> should free normally when it leaves scope, so I'm pretty sure this wouldn't happen. I could be wrong though.

@H2CO3

Rc<RefCell<_>> also moves exclusivity checking from compile-time to runtime, which means you would likely run into several panics related to multiple mutable borrows.

If I unwrapped the Rc<RefCell<_>> each time I needed the value and dropped the handle as soon as I finished with it, I'm pretty sure this wouldn't happen. Horrific runtime cost, but I don't think it would panic.

@H2CO3

There would be many spurious heap allocations and redundant reference counting operations, as Rc is not a language built-in, and the optimizer doesn't magically know how to eliminate it.

Yep, tons. It would be the absolute worst. For code that doesn't need to run fast, that shouldn't matter though.

@H2CO3

Relatedly, doing this would impede thread-safety or incur an unacceptable runtime cost. Rc<RefCell> is not thread-safe, so if you wrapped everything in it, you won't be able to write threaded or async code at all. On the other hand, if you used the thread-safe equivalent, Arc<Mutex> , that would mean locking every single variable , even trivially thread-safe locals, for no reason.

While locking every single variable is absolutely awful, code that doesn't need to run fast would probably still be okay if it did that. There's also the question of how much code there really is that needs to be multithreaded, but doesn't need to run fast.

@H2CO3

Pattern matching would also become disproportionately more difficult, as you can't directly match the wrapped value of an Rc by value or by mutable reference.

You got me there. Pattern matching is one of the things that I like the most about rust's syntax, and it would be such a shame to lose it. I think nesting match statements would be able to get around it and make it work, but that's such an ugly thing to need to do.

@H2CO3

TL;DR: if you find Rust hard due to the borrow checker, tacking a Rc<RefCell> onto every value won't help with that, and would likely result in code that is way inferior to idiomatically written Rust code.

I actually love the borrow checker and don't fight with it that much at all, I just sometimes wish there was a language that was identical to rust but didn't make me think about where data is owned, so I could prototype faster. I think it's also an interesting question as to whether that hypothetical language has a relatively simple mapping to valid rust code, because it felt like it might, and knowing why or why not would help me understand the language a little better. If it is possible to make it work at all, there's probably a fancy way to optimize out a lot of the unnecessary heap allocations, and that may even result in it generating idiomatic rust code if the input code is written in a way that makes it possible.