Auto merge of #29138 - ykomatsu:trpl2, r=Manishearth
This commit is contained in:
commit
ea2dabf6b2
@ -48,7 +48,7 @@ Systems Level
|
||||
Language](http://www.cs.indiana.edu/~eholk/papers/hips2013.pdf). Early GPU work by Eric Holk.
|
||||
* [Parallel closures: a new twist on an old
|
||||
idea](https://www.usenix.org/conference/hotpar12/parallel-closures-new-twist-old-idea)
|
||||
- not exactly about rust, but by nmatsakis
|
||||
- not exactly about Rust, but by nmatsakis
|
||||
* [Patina: A Formalization of the Rust Programming
|
||||
Language](ftp://ftp.cs.washington.edu/tr/2015/03/UW-CSE-15-03-02.pdf). Early
|
||||
formalization of a subset of the type system, by Eric Reed.
|
||||
|
@ -204,7 +204,7 @@ borrow checker. Generally we know that such mutations won't happen in a nested f
|
||||
to check.
|
||||
|
||||
For large, complicated programs, it becomes useful to put some things in `RefCell`s to make things
|
||||
simpler. For example, a lot of the maps in [the `ctxt` struct][ctxt] in the rust compiler internals
|
||||
simpler. For example, a lot of the maps in [the `ctxt` struct][ctxt] in the Rust compiler internals
|
||||
are inside this wrapper. These are only modified once (during creation, which is not right after
|
||||
initialization) or a couple of times in well-separated places. However, since this struct is
|
||||
pervasively used everywhere, juggling mutable and immutable pointers would be hard (perhaps
|
||||
|
@ -150,7 +150,7 @@ owners!
|
||||
So, we need some type that lets us have more than one reference to a value and
|
||||
that we can share between threads, that is it must implement `Sync`.
|
||||
|
||||
We'll use `Arc<T>`, rust's standard atomic reference count type, which
|
||||
We'll use `Arc<T>`, Rust's standard atomic reference count type, which
|
||||
wraps a value up with some extra runtime bookkeeping which allows us to
|
||||
share the ownership of the value between multiple references at the same time.
|
||||
|
||||
|
@ -279,11 +279,11 @@ fn extension(file_name: &str) -> Option<&str> {
|
||||
}
|
||||
```
|
||||
|
||||
One other pattern that we find is very common is assigning a default value to
|
||||
the case when an `Option` value is `None`. For example, maybe your program
|
||||
assumes that the extension of a file is `rs` even if none is present. As you
|
||||
might imagine, the case analysis for this is not specific to file
|
||||
extensions - it can work with any `Option<T>`:
|
||||
One other pattern we commonly find is assigning a default value to the case
|
||||
when an `Option` value is `None`. For example, maybe your program assumes that
|
||||
the extension of a file is `rs` even if none is present. As you might imagine,
|
||||
the case analysis for this is not specific to file extensions - it can work
|
||||
with any `Option<T>`:
|
||||
|
||||
```rust
|
||||
fn unwrap_or<T>(option: Option<T>, default: T) -> T {
|
||||
|
Loading…
Reference in New Issue
Block a user