<i>simple dereferencing and assigning a value of a field in a structure to a variable means the structure is now borrowed and you can&#x27;t reference the field nor the structure until the variable goes out of scope; please, for the love of all that is holy, prove me wrong!</i><p>This is only partially true. If you hold a mutable reference to a field in a structure, you can&#x27;t get a reference to the entire structure. (Think of a mutable reference as a read-write lock, because that&#x27;s what it <i>is</i>, just at compile time &#x2F; type level instead of at runtime.) However, you can get a mutable reference to other fields in the structure. And an immutable reference to a field (analogous to a read-only &#x2F; shared lock) does not prevent other immutable references, so you can totally get a reference to the structure while a reference to one of its fields is outstanding.<p>Here&#x27;s an example of this on play.rust-lang.org: <a href="http:&#x2F;&#x2F;is.gd&#x2F;ySSsex" rel="nofollow">http:&#x2F;&#x2F;is.gd&#x2F;ySSsex</a><p>That compiles and runs with the extra scope around the mutable borrows. If you comment out that scope, then yes, it won&#x27;t compile.<p>My experience, coming to Rust from C++ and C, is that a lot of real-world C++ and C code is imprecise about mutability and shared references, and relies on the programmer not doing anything particularly weird. It&#x27;s true that in this example, nothing would go wrong by omitting the braces because the references g and h aren&#x27;t actually used. But in larger and legacy codebases, it&#x27;s very easy to forget the mutability rules that were in the head of the previous programmer. So directly porting C++ code is going to be annoying, but that&#x27;s mostly because the hard work is figuring out what was implicit in the C++.