Tiny typo changes (per discussion in pull request #22027)
This commit is contained in:
parent
526e748846
commit
918d097c8e
@ -15,7 +15,7 @@ comments":
|
||||
// the "link" crate attribute is currently required for rustdoc, but normally
|
||||
// isn't needed.
|
||||
#![crate_id = "universe"]
|
||||
#![crate_type = "lib"]
|
||||
#![crate_type= lib"]
|
||||
|
||||
//! Tools for dealing with universes (this is a doc comment, and is shown on
|
||||
//! the crate index page. The ! makes it apply to the parent of the comment,
|
||||
|
@ -75,8 +75,7 @@ This is a deliberate design decision. While full-program inference is possible,
|
||||
languages which have it, like Haskell, often suggest that documenting your
|
||||
types explicitly is a best-practice. We agree that forcing functions to declare
|
||||
types while allowing for inference inside of function bodies is a wonderful
|
||||
sweet spot between full inference and no inference. (For closures, i.e. unnamed
|
||||
functions, types do not have to be declared.)
|
||||
sweet spot between full inference and no inference.
|
||||
|
||||
What about returning a value? Here's a function that adds one to an integer:
|
||||
|
||||
|
@ -23,7 +23,7 @@ match x {
|
||||
`match` takes an expression and then branches based on its value. Each *arm* of
|
||||
the branch is of the form `val => expression`. When the value matches, that arm's
|
||||
expression will be evaluated. It's called `match` because of the term 'pattern
|
||||
matching,' which `match` is an implementation of.
|
||||
matching', which `match` is an implementation of.
|
||||
|
||||
So what's the big advantage here? Well, there are a few. First of all, `match`
|
||||
enforces *exhaustiveness checking*. Do you see that last arm, the one with the
|
||||
|
@ -61,7 +61,7 @@ multiplications later, and we have our area.
|
||||
## Chaining method calls
|
||||
|
||||
So, now we know how to call a method, such as `foo.bar()`. But what about our
|
||||
original example, `foo.bar().baz()`? This is called 'method chaining,' and we
|
||||
original example, `foo.bar().baz()`? This is called 'method chaining', and we
|
||||
can do it by returning `self`.
|
||||
|
||||
```
|
||||
|
@ -14,7 +14,7 @@ Rust has two main types of strings: `&str` and `String`.
|
||||
|
||||
# &str
|
||||
|
||||
The first kind is a `&str`. This is pronounced a 'string slice.'
|
||||
The first kind is a `&str`. This is pronounced a 'string slice'.
|
||||
String literals are of the type `&str`:
|
||||
|
||||
```
|
||||
|
@ -648,8 +648,8 @@ The `rustc` compiler has certain pluggable operations, that is,
|
||||
functionality that isn't hard-coded into the language, but is
|
||||
implemented in libraries, with a special marker to tell the compiler
|
||||
it exists. The marker is the attribute `#[lang="..."]` and there are
|
||||
various different values of `...`, i.e. various different "lang
|
||||
items."
|
||||
various different values of `...`, i.e. various different 'lang
|
||||
items'.
|
||||
|
||||
For example, `Box` pointers require two lang items, one for allocation
|
||||
and one for deallocation. A freestanding program that uses the `Box`
|
||||
|
Loading…
x
Reference in New Issue
Block a user