Mention that it's not actually a data race

[Manishearth]

The example can't cause a data race since different indices are accesed.

(perhaps we should use an example where i iterates twice?)

r? @steveklabnik

[tobz]

(Rust newbie here, just for context)

Is it the compiler actually looking and saying: "well, data is being access in another thread, so it's not safe" or simply that it's being accessed in a closure, another scope, somewhere where data could change out from under it?

I understand the wording being used is because of the nature of explaining concurrency -- which boils down to threads -- but it seems like it might be clearer to express it in the general terms that the Rust documentation seems to explain ownership.... so long as that's what the compiler sees. If the compiler actually can differentiate between where data is being accessed from, then I mostly take back this entire comment. :P

Just a thought.

[Manishearth]

Is it the compiler actually looking and saying: "well, data is being access in another thread, so it's not safe" or simply that it's being accessed in a closure, another scope, somewhere where data could change out from under it?

Somewhat the latter, but not exactly. What the compiler sees (and what you should see too) is that data was moved out, so it doesn't even exist to be used again the second time around. It doesn't notice the concurrency issues, not just yet.

[tobz]

The current wording feels like 75% about how a smart, outside observer can tell that the individual indices could be safely mutated without stepping on each other, and the other 25% is about what situation could actually cause a problem. The whole paragraph seems to ignore the explanation you posted above.

Does my summary make sense to you? Do you think it would be clearer to make a small mention, something along the lines of: "while this program may not appear to overwrite individual indices, the compiler cannot infer which pieces of the data are being operated on, only that the variable has been moved elsewhere and isn't eligible for use when we go to spawn the second thread" ?

[Manishearth]

I'd prefer if the program was modified so that it does conflict indices :)

[tobz]

Ha! Given the section is about concurrency, fair enough.

I guess I would just like to put in a suggestion/plea for any explanation of the "data moving" aspect. As a Rust newbie, the ownership system is consistently the hardest piece of Rust to understand/remember. If that's the actual/current reason why the compiler complains, then it seems fitting to tell that.

At any rate, it's awesome to see the documentation be so quickly updated, driven by random comments on HN no less. :)

[Manishearth]

The assumption here is that you've read the chapter on ownership and are very clear on what moving is by the time you reach this chapter 😄

(The full compiler error on this actually links to an extended explanation on ownership that is pretty nice too)

[tobz]

Got me again! A fair point, indeed. :)

[bors]

☔ The latest upstream changes (presumably #32529) made this pull request unmergeable. Please resolve the merge conflicts.

[steveklabnik]

@Manishearth: this is out of date, but r=me whenever you rebase it :)

[Manishearth]

@bors r=steveklabnik

[bors]

📌 Commit a447124 has been approved by steveklabnik

[Manishearth]

@bors rollup