doc-book: Improve clarity of Sync in Concurrency

[critiqjo]

Fixes#28458

Details about Arc may be too soon to be described together with Sync... Tell me what you think.

r? @steveklabnik

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @steveklabnik (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[critiqjo]

The above code snippet without Arc will most likely be thought of like this, which gives a "capture of moved value" error...

[critiqjo]

I have incorporated the changes you suggested. Please have a look at them...

[steveklabnik]

Will try to do tonight or tomorrow.

[critiqjo]

Made a few more improvements...

[critiqjo]

Do you think it is unnecessary to point out "i at the time of spawn()" (yet again)..?

[steveklabnik]

i think it's fine.

[critiqjo]

I was reading "Closures" and found some scope for improvement in Returning closures:

But why doesn’t our closure implement &'static Fn? Well, as we discussed before, closures borrow their environment. And in this case, our environment is based on a stack-allocated 5, the num variable binding. So the borrow has a lifetime of the stack frame.

But shouldn't the primary reading of the error message be "expected a static reference, found an object"? Further, we could point out that one cannot -- create something, turn it into a static object, and then return a static reference to it...

The "reference to stack allocated num" part can be explained after the next example block...

If you agree with me in this, shall I make these changes in this PR (as a second commit), or should I issue a new PR?

[steveklabnik]

@critiqjo yeah, let's keep the two things separate. I'm not sure exactly what you mean, but I'd rather talk about it in a new issue and or PR

[steveklabnik]

@bors: r+ rollup

[bors]

📌 Commit a0f214e has been approved by steveklabnik