reference

Ok, I've made some notes after reading this thread a few times and reading the specs. I think I have a better understanding: Pointer aliasing rules: - &T must not be mutated while live (except for UnsafeCell<U>) - UnsafeCell is special in that it tells the compiler mutation can happen so it won't store things in registers - &mut T must not be read or written by a pointer not derived from this reference, and no other reference should point to it while the &mut T is live - Liveliness is not concretely specified but not important for these notes (Read from doc.rust-lang.org ) This is separate but related to the borrow checker which ensures these invariants stay true within safe Rust. Unsafe Rust must do extra work to ensure they are valid. UnsafeCell lets you move enforcement of these invariants from the borrow checker to runtime. The aliasing rules don't apply to raw pointers which kind of makes sense since those aren't really rust values, they just point to things. But if you use raw pointers you can violate the aliasing of other values. For example: fn main() { let mut x: u32 = 1; let ptr: *mut u32 = &mut x; x = 1; unsafe { std::ptr::write(ptr, 1) }; // writes over the 'mut x' reference println!("x is {}", x); } This isn't allowed of course. (Read from doc.rust-lang.org ) One big question I've had is how foreign code interacts with this idea of aliasing. C for example allows you to do a lot of things that Rust doesn't. Is it sound to expose C code that does Rust UB that isn't C UB? I had a look online and the answer is apparently 'yes', things that are UB in Rust but valid in C don't become UB just by calling it from Rust: reference#485 This thread is also a good read, I like the diagram Kevin gave that empahsizes that soundness is a shared property across FFI boundaries. users.rust-lang.org Returning to the topic of interior mutability, thinking of &mut and & as unique versus shared makes sense. Having shared access to some T doesn't necessarily mean it will not be mutated. Having unique access to some T doesn't necessarily mean it will be mutated either. But for soundness Rust requires unique access for mutation of values in memory, which makes sense.