To be pedantic, the borrow checker actually doesn't impact semantics. The choice of which pointer type to use, e.g. a reference vs. Rc vs. Box, does impact sem

To be pedantic, the borrow checker actually doesn't impact semantics. The choice of which pointer type to use, e.g. a reference vs. Rc vs. Box, does impact semantics. And your broader point is well taken: since that choice affects semantics, it's really something you have to consider as you're designing your data structures; it doesn't really make sense to design the program first and tack on memory management at the end, like the parent is suggesting. But that's not the borrow checker. For comparison, C++ has very similar behavior around smart pointers, but no borrow checker. Also, destructors are lexically scoped: a variable's destructor will be run when it goes out of scope, no earlier. The borrow checker used to be lexically scoped as well, but it's gotten smarter over time [1], and a borrow can now end in the middle of a block, if the borrow checker sees that the borrowed data is no longer used afterwards. Yet this has intentionally not been extended to include types with destructors, on the grounds that Rust code sometimes relies on destructor timing for correctness (in ways that the borrow checker can't see), so running destructors early could cause breakage, which would be hard for code authors to spot by just looking at the code. This same lack of predictability is considered acceptable for the borrow checker precisely because it doesn't affect runtime semantics. [1] https://stackoverflow.com/questions/50251487/what-are-non-lexical-lifetimes https://stackoverflow.com/questions/50251487/what-are-non-le...