rust
/
book
mirror of https://github.com/rust-lang/book
1
0
Fork 0
Code Issues Releases Wiki Activity

Merge pull request #1111 from bmusin/patch-7 

fix typos
This commit is contained in:
Carol (Nichols || Goulding) 2018-01-12 16:05:49 -05:00 committed by GitHub
parent 345c0ef8e8 282c3a3e93
commit ea83bbc207
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
first-edition/src/choosing-your-guarantees.md
View File

@ -4,8 +4,8 @@ One important feature of Rust is that it lets us control the costs and guarantee
of a program.
There are various “wrapper type” abstractions in the Rust standard library which embody
a multitude of tradeoffs between cost, ergonomics, and guarantees. Many let one choose between
run time and compile time enforcement. This section will explain a few selected abstractions in
a multitude of trade-offs between cost, ergonomics, and guarantees. Many let one choose between
run-time and compile-time enforcement. This section will explain a few selected abstractions in
detail.
Before proceeding, it is highly recommended that one reads about [ownership][ownership] and
@ -86,7 +86,7 @@ last. It's a viable alternative to `&T` when `&T` is either impossible to static
correctness, or creates extremely unergonomic code where the programmer does not wish to spend the
development cost of working with.
This pointer is _not_ thread safe, and Rust will not let it be sent or shared with other threads.
This pointer is _not_ thread-safe, and Rust will not let it be sent or shared with other threads.
This lets one avoid the cost of atomics in situations where they are unnecessary.
There is a sister smart pointer to this one, `Weak<T>`. This is a non-owning, but also non-borrowed,
@ -243,7 +243,7 @@ At runtime each borrow causes a modification/check of the refcount.
Many of the types above cannot be used in a threadsafe manner. Particularly, `Rc<T>` and
`RefCell<T>`, which both use non-atomic reference counts (_atomic_ reference counts are those which
can be incremented from multiple threads without causing a data race), cannot be used this way. This
makes them cheaper to use, but we need thread safe versions of these too. They exist, in the form of
makes them cheaper to use, but we need thread-safe versions of these too. They exist, in the form of
`Arc<T>` and `Mutex<T>`/`RwLock<T>`
Note that the non-threadsafe types _cannot_ be sent between threads, and this is checked at compile
@ -271,7 +271,7 @@ behavior, so even monotonicity may not be enough to justify `UnsafeCell`.
#### Guarantees
Like `Rc`, this provides the (thread safe) guarantee that the destructor for the internal data will
Like `Rc`, this provides the (thread-safe) guarantee that the destructor for the internal data will
be run when the last `Arc` goes out of scope (barring any cycles).
#### Cost
@ -354,7 +354,7 @@ When reading code that uses these, go in step by step and look at the guarantees
When choosing a composed type, we must do the reverse; figure out which guarantees we want, and at
which point of the composition we need them. For example, if there is a choice between
`Vec<RefCell<T>>` and `RefCell<Vec<T>>`, we should figure out the tradeoffs as done above and pick
`Vec<RefCell<T>>` and `RefCell<Vec<T>>`, we should figure out the trade-offs as done above and pick
one.
[^3]: `&[T]` and `&mut [T]` are _slices_; they consist of a pointer and a length and can refer to a portion of a vector or array. `&mut [T]` can have its elements mutated, however its length cannot be touched.