don't use `RefCell<T>` · riki's house

hey! looks like you have JavaScript disabled.
I respect that decision, but you may find the experience of browsing the treehouse… not great.
for example, links to branches may not work properly. I cannot do anything about this; it's due to how the <details> element works.
(a <details> will not expand itself automatically to reveal the linked element to you.)
I did my best to at least keep the site readable in this state, but you can only do so much with plain HTML and CSS.

Pinky promise this website does not contain any malicious code such as trackers or cryptocurrency miners.
if you don't believe me, you're free to inspect the source yourself! all the scripts are written lovingly in vanilla JS (not minified!) by yours truly ❤️

and if this box is annoying, feel free to block it with uBlock Origin or something. I have no way of remembering you closed it, and don't wanna add a database to this website. simplicity rules!

usually if you have to resort to RefCell<T>, it means something is wrong with your architecture
2023-10-10
- Cell<T> less so but still you should avoid it whenever possible
  2023-10-10
- Rc<RefCell<T>> is an immediate red flag when I read someone’s code. it means they don’t really know what they’re doing and are just trying to sidestep the language
  2023-10-10
it’s really not that hard to avoid, try bumping your resources up a scope and borrow them from there
2023-10-10
using RefCell has a few disadvantages
2023-10-10
- first, RefCell is literally turning off the borrow checker
  2023-10-10
  - or really deferring it until runtime, but then what’s the point. Rust’s borrowing rules are meant to prevent bugs, not cause more of them
    2023-10-10
- second, your program can now panic in unexpected places, because it turns out runtime borrows can be really hard to predict
  2023-10-10
  - as evidenced by a random crash I once got while using druid which was caused by a overlapping mutable then immutable borrows at runtime
    2023-10-10
    therefore maybe uhhh… don’t use it in libraries? :pleading:
    2023-10-10
- third, it incurs a runtime overhead for the borrow checking, which in 99% of cases is totally unnecessary
  2023-10-10
  - (this is more about non-pessimization rather than premature microoptimization, so don’t yell at me with your “it’ll be fast enough” arguments please)
    2023-10-10
- fourth, and this one is extremely easy to spot - your code becomes really verbose!
  2023-10-10
  - yes please, .borrow() me everywhere!
    2023-10-10
  - and you end up with lots of temporaries because of the Ref<'b, T> guards you have to keep in scope.
    2023-10-10
    remember that you cannot do &ref_cell.borrow().some_field because that would drop the temporary Ref<'b, T> guard after the expression ends
    2023-10-10