[aratakareigen]

Rust types have markers (Send, Sync) that tell the compiler whether they can be moved across threads, and whether they can be simultaneously accessed across threads.

These markers are irrelevant in a single-threaded scenario.

[steveklabnik]

It's not purely about those markers. Many people also believe that the only issue with aliasing is when threads come into play, but that's not the case. Rust also prevents mutable aliasing even in non-threaded cases for this reason.

[giovannibajo1]

Is there any explanation of this? Specifically i would like to understand how a single mutable reference is required for correctness in a single thread scenario.

I’ve googled everywhere but I can’t find a single source of information that completely explains this, possibly showing realistic source code and elaborating the way it could generate memory errors or be miscompiled in case of multiple mutable references.

[steveklabnik]

https://manishearth.github.io/blog/2015/05/17/the-problem-wi... is what I usually link folks to.

The TL;DR is: iterator invalidation can happen even without threads.

[giovannibajo1]

Thanks, exactly what I was looking for!

[aratakareigen]

For example, if I could push to a Vec while holding a slice to it, that would obviously lead to horrible behavior if the Vec needed to reallocate.

Another example is if someone tried to use a Vec x inside the closure passed to x.drain.

[aratakareigen]

Right, but the question was:

> doesn’t Rust refuse to compile even when you use non-concurrency safe objects in a single thread?

and given that most types (Vec, HashMap, etc.) aren't "concurrency-safe" (thread-safe?), your answer

> yes

is rather perplexing.