New Cell docs #48474
New Cell docs #48474
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (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. Due to 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. |
rust-highfive
added
the
S-waiting-on-review
src/libcore/cell.rs
Outdated
| //! Rust memory safety is based on this rule: Given an object `T`, is only possible to | ||
| //! have one of the following: | ||
| //! | ||
| //! - Having several inmutable references (`&T`) to the object (also know as Aliasing). |
src/libcore/cell.rs
Outdated
| //! controlled manner. Both `Cell<T>` and `RefCell<T>` allows to do this in a single threaded | ||
| //! way. However, neither `Cell<T>` nor `RefCell<T>` are thread safe (they do not implement | ||
| //! `Sync`), if you need to do Aliasing and Mutation between multiple threads is possible to use | ||
| //! `Mutex`, `RwLock` or `AtomicXXX`. |
There was a problem hiding this comment.
We should probably link to these types here.
src/libcore/cell.rs
Outdated
| @@ -10,6 +10,22 @@ | |||
|
|
|||
| //! Shareable mutable containers. | |||
| //! | |||
| //! Rust memory safety is based on this rule: Given an object `T`, is only possible to | |||
src/libcore/cell.rs
Outdated
| //! - Having one mutable reference (`&mut T`) to the object (also know as Mutability). | ||
| //! | ||
| //! This is enforced by the Rust compiler. However, there are situations where this rule is not | ||
| //! flexible enough. Sometimes is required to have multiple references to an object and yet |
src/libcore/cell.rs
Outdated
| //! flexible enough. Sometimes is required to have multiple references to an object and yet | ||
| //! mutate it. | ||
| //! | ||
| //! Shareable mutable containers exist to permit mutability in presence of aliasing in a |
There was a problem hiding this comment.
Should be "in the presence"
|
Ok I've done the pertinent changes! Thank you all for your feedback :) |
src/libcore/cell.rs
Outdated
| //! Rust memory safety is based on this rule: Given an object `T`, it is only possible to | ||
| //! have one of the following: | ||
| //! | ||
| //! - Having several immutable references (`&T`) to the object (also know as Aliasing). |
There was a problem hiding this comment.
s/know as/known as/
s/Aliasing/**aliasing**/ . Capitalization of common nouns is unnatural in English, and when it is done, it generally implies that the capitalized noun has a much more specific (and widely understood) definition than the lowercase noun (e.g. "Undefined Behavior" is not the same thing as "undefined behavior"). This is unnecessary for a word like "aliasing" which is already uncommon.
The reason I suggest bold here is because you are introducing a definition for it.
src/libcore/cell.rs
Outdated
| //! have one of the following: | ||
| //! | ||
| //! - Having several immutable references (`&T`) to the object (also know as Aliasing). | ||
| //! - Having one mutable reference (`&mut T`) to the object (also know as Mutability). |
There was a problem hiding this comment.
s/know as/known as/
s/Mutability/**mutability**/
src/libcore/cell.rs
Outdated
| //! flexible enough. Sometimes it is required to have multiple references to an object and yet | ||
| //! mutate it. | ||
| //! | ||
| //! Shareable mutable containers exist to permit mutability in the presence of aliasing in a |
There was a problem hiding this comment.
"in ___ in ___" reads a bit awkward. I might write:
Before: ...to permit mutability in the presence of aliasing in a controlled manner
After: ...to permit mutability in a controlled manner, even in the presence of aliasing.
src/libcore/cell.rs
Outdated
| //! Shareable mutable containers exist to permit mutability in the presence of aliasing in a | ||
| //! controlled manner. Both `Cell<T>` and `RefCell<T>` allows to do this in a single threaded | ||
| //! way. However, neither `Cell<T>` nor `RefCell<T>` are thread safe (they do not implement | ||
| //! `Sync`), if you need to do Aliasing and Mutation between multiple threads is possible to use |
There was a problem hiding this comment.
Use period instead of comma after these parentheses.
Add comma after "threads".
Missing "it" before "is possible."
Don't capitalize (or emphasize) aliasing and mutation.
Sync). If you need to do aliasing and mutation between multiple threads, it is possible to use
|
Ping from triage, @steveklabnik ! |
|
I am not likely to be able to review until late tomorrow, possibly tuesday. Sorry about that! |
|
@bors: r+ rollup So sorry about the delay, this is great. Thanks so much! |
|
📌 Commit 9091584 has been approved by |
bors
added
S-waiting-on-bors
…eveklabnik New Cell docs This fixes rust-lang#44061
…eveklabnik New Cell docs This fixes rust-lang#44061
This fixes #44061