This is sort of a question, but doesn’t Rust refuse to compile even when you use...

aratakareigen · on March 2, 2020

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 · on March 2, 2020

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 · on March 2, 2020

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 · on March 2, 2020

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 · on March 4, 2020

Thanks, exactly what I was looking for!

aratakareigen · on March 4, 2020

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 · on March 4, 2020

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.

steveklabnik · on March 2, 2020

It is the case, yes.