In the given example they are not using the shared reference at all during the whole lifetime of the immutable reference and the operation on the immutable one does not change the object at all, so it would be actually safe. This is the situation where those two rules are a bit too strict and reject a valid program.
> In the given example they are not using the shared reference at all during the whole lifetime of the immutable reference and the operation on the immutable one does not change the object at all, so it would be actually safe.
The compiler does not work at that level of resolution. It’s unclear that it should, even for a point query: there is no telling how much a weirdo ISA would bungle that if the two accesses came from different threads, for instance.
> This is the situation where those two rules are a bit too strict and reject a valid program.
Compilers will always, necessarily, reject valid programs. The alternative is to allow invalid programs.
Re:Some Thoughts on Zig
by ArrayBoundCheck on Friday July 22, 2022 @02:51PM
(#32195741)
> The compiler does not work at that level of resolution. It’s unclear that it should
The correct solution is to never ever use rust. It's a failed experiment that noone noticed failed
Limitations are when the borrow checker is not smart enough to understand things like sub-scope borrows (fixed by NLL) or the interaction of mutable borrows and loops (which hopefully will eventually be fixed by Polonius aka NLLv2).
But here they want to acquire a shared reference to an object with an outstanding unique reference. That is quite literally the first of only two rules references have:
1. At any given time you can have either a single unique reference or multiple shared references.
2. References must be valid.