Checking where references remain in use
A reference must not outlive the value it borrows. Rust’s borrow checker enforces these validity constraints, rejecting cases such as returning a reference to a local value that will be dropped.
Borrowing also constrains aliasing and mutation: while relevant borrows are active, the ordinary model allows either one exclusive mutable reference or multiple shared references. This concerns overlapping uses, not simply how many reference expressions appear in the source.
The last use can precede the block’s end
A reference’s relevant use does not always continue to its block’s closing brace. The Rust Book demonstrates creating a mutable reference after the final use of earlier shared references within the same block.
Tracking actual uses permits sequences that do not overlap in the problematic way. Reusing an earlier shared reference after mutation creates different constraints. Name visibility and the period during which a borrow must remain valid should not be treated as identical.
References: [1]
Static and dynamic checking have different boundaries
Static analysis makes conservative decisions from available information; rejection does not prove that every execution would fail. Lifetime annotations can express relationships among references but cannot arbitrarily extend the existence of the borrowed value.
RefCell<T> checks the relevant borrowing rules at runtime and panics on a violation. Unsafe implementations must uphold their safe interface’s conditions. Passing borrow checking likewise does not establish algorithmic correctness beyond the properties being checked.