2 ms·

While this obviously and uncontroversially true in an absolute sense (the borrowck isn’t perfect), I think in the overwhelming majority of real-world cases its

While this obviously and uncontroversially true in an absolute sense (the borrowck isn’t perfect), I think in the overwhelming majority of real-world cases its concerns are either actual problems with your design or simple and well-known limitations of the checker that have pretty straightforward and idiomatic workarounds. I haven’t seen a lot of programs designs in practice that are sound but fundamentally incompatible with the borrow checker. Every time I’ve thought this I’ve come to realize there was something subtly (or not so subtly) wrong with the design. I have seen some contrived cases where this is true but they’re inevitably approaches nobody sane would actually want to use anyway.

cogman10 2y ago
Here's something not contrived that does pretty frequently come up [1] The gist of it is even though tasks can be somewhat guaranteed to live only for the scope of the current method, you can't guarantee that with the rust type system. The end result is needing to copy immutable data or use ARC needlessly. It's annoying enough that the language added "scoped_threads" which work great, but can't be translated into rust async tasks. [1] https://without.boats/blog/the-scoped-task-trilemma/ https://without.boats/blog/the-scoped-task-trilemma/