[oconnor663]

If you do this, make sure you find a way to test your code under Miri. Unsafe workarounds to this problem might appear to work in practice but are often unsound according to the (likely, future) formal memory model. The situation is similar to a strict aliasing violation in C/C++, where trivial-seeming changes to surrounding code (or flags, or the compiler version) can turn a "benign" or "latent" violation into observable UB.

[Cloudef]

One doesnt always have to care about async / future / threading. Especially if its store once, read after data.

Unless you are saying rust can do whatever it wants with its memory without clear specification nor way for you to force it to certain direction, then my answer is that rust has failed as a low level language at that point.

[oconnor663]

It's really the exact same situation with strict aliasing violations in C and C++. If you break the rules (which are different depending on the language but in any case kind of complicated) all bets are off, even in totally single-threaded code, even if all you're doing is integer arithmetic, and in fact even if your code passes ASan and UBSan. If you'll pardon some shameless self-promotion, I have a talk about this that goes into a lot of examples: https://www.youtube.com/watch?v=DG-VLezRkYQ

The nice thing about Rust is that you mostly don't have to worry about any of this if you don't write the "unsafe" keyword. Folks with previous C and C++ experience often come in with understandable but mistaken assumptions about how unsafe code works in Rust, and I think it's important to study the rules carefully before you start writing unsafe code for production use.