What memory model should Rust use?
Relegating parts of the memory model with unclear&#x2F;hard-to-specify semantics (i.e. relaxed or consume) to the &quot;unsafe&quot; part of the language is an interesting idea, but it kind of goes against the spirit of &quot;unsafe&quot; (this point is debatable, of course).<p>The purpose of the unsafe keyword is to mark code that could cause safety issues (undefined behavior) if its expectations about the surrounding code are not met. (e.g., an unchecked array access expects its index to be in bounds).<p>With unlimited time and resources, it should be possible to give a mathematical proof about those unsafe blocks, showing that their expectations are met and that undefined behavior will not actually occur (by for example proving that the array index supplied will always be in bounds).<p>But since relaxed and consume have unclear semantics, it hard to formally reason about the correctness of any code that uses them (and it is also hard to build tools to do that checking, as mentioned).<p>So in an ideal world, we would have a 100% clear semantics for all parts of the language, _including_ the unsafe fragment. Unsafe should not be a place to put poorly specified languages features.<p>Of course, we don&#x27;t live in this ideal world, but I would rather hope for fixing the memory model so that it be made completely formal and precise (if necessary, giving up some currently allowed compiler&#x2F;hardware optimizations if they&#x27;re more trouble than they are worth). As an extreme example, sequential consistency is easy to understand as long as you don&#x27;t mix it with other types of atomic accesses and avoid non-atomic data races.