Thinking about implications of strong aliasing rules and move semantics in Rust in context of unsafe code let me wondering how much more tricky it is to write unsafe code compared to C.
Rust does not allow value to be aliased by multiple pointers and programmer has to account for this manually in unsafe code. In contract C/C++ compilers use defensive alias analysis which leads to lower performance when the writing to memory through references or pointers because of excessive loads and stores but code aliasing single memory location by multiple pointers runs correctly. Also C compilers treat function calls as load/store barriers because they must expect that any memory can be accessed or changed inside the called function.
Rust could get rid of the alias analysis and excessive stores and loads. I do not know if it already does. However in that case it is not possible to modify any memory location that is referenced by immutable reference or raw pointer. The C/C++ has mutable keyword to allow modifications to data even through const references and comes handy for lazy initializations and similar situations. Because of its aliasing rules it is not problem. In Rust that is big problem because caller may not see changes.
Is it allowed to modify data behind immutable references in unsafe code? If yes, does it mean that these load/store optimizations will never happen? If no, what is a solution to situation where mutable is used in C++?