Use result of the computation to prevent the compiler from optimising
too much. Change `_x` to `x` and therefore remove the paragraph about
the underscore.
Fixes#25855.
r? @steveklabnik
Use result of the computation to prevent the compiler from optimising
too much. Change `_x` to `x` and therefore remove the paragraph about
the underscore.
Fixes#25855.
Explain the --bin flag in terms of the difference
between shipping binary and library code
I'm not sure if my explanation is even quite correct, but as a newbie coming from Ruby, this is my best guess. (In Rubyland, libraries always ship with the source code because there's no other form you can ship. :) )
In the discussion of returning closures, it seems like the example code got simplified, but only the later copies got fixed. The final working code has `factory` returning `|x| x + num`, but the earlier code has `|x| vec.push(x)`.
The first form seemed to have more distracting characteristics, and the code wasn't right anyway, so I changed them to all use the second form, and updated the error messages.
r? @steveklabnik
Doc patch for #26120. Extra words here, because "value" is repeated.
I haven't read about whether/how it should go to stable (sorry), but I think it would help newcomers.
Thanks,
The text claimed 'any borrow must last for a _smaller_ scope than the
owner', however the accurate way of describing the comparison is
inclusive (i.e., 'less than or equal to' vs. 'less than').
For a user following the path of reading Chapter 5: Syntax & Symantics
prior to Chapter 4: Learn Rust, this will be the first time they have
encountered executable tests inside documentation comments.
The test will fail because the `add_one` function is not defined in
the context of the doctest. This might not be the optimal place to
introduce and explain the `/// #` notation but I think it is important
that this snippet pass as a test when `rustdoc --test` is run against
it.
The doc indicates that you can replace 'before' with 'after' showing the use of try!. The two examples should be equivalent, but they are not.
In the File::create we were inducing a panic before in case of error, not propagating. It is important for newbies (like myself) to understand that try! propagates failures, while unwrap can induce a panic.
The other alternative is to make the 'before' File::create also manually handle Err like the other calls. Either way it would be consistent.
As mentioned in #25893 the copy trait is not very well explained for beginners. There is no clear mention that all primitive types implement the copy trait and there are not a lot of examples.
With this change I try to make it more visible and understandable for new users.
I myself have struggled with this, see [my question on stackoverflow](http://stackoverflow.com/questions/30540419/why-are-booleans-copyable-even-though-the-documentation-doesnt-indicate-that). And I want to make it more transparent for others.
I filed issue #25893 but I thought that I could give it a shot myself to relieve some of the work from the devs :)
If it is not well written or there are some changes to be made before it can be merged, let me know.
Cheers,
Mathieu
For a user following the path of reading Chapter 5: Syntax & Symantics
prior to Chapter 4: Learn Rust, this will be the first time they have
encountered executable tests inside documentation comments.
The test will fail because the `add_one` function is not defined in
the context of the doctest. This might not be the optimal place to
introduce and explain the `/// #` notation but I think it is important
that this snippet pass as a test when `rustdoc --test` is run against
it if it is going to be shown.
The sensible default used here for the version number in the
auto-generated Cargo.toml is 0.1.0, not 0.0.1 (at least as of cargo
0.2.0-nightly efb482d).
The statement is not completely exact, because it is valid to have
both 0 non-mutable references and 1 mutable reference. Instead, use
the same wording as in mutability.md.
Hi
I added a little section in the for loops about the `enumerate()` function.
I think it's useful for beginners to know this function and how you can use it.
I used the title loopcounter, but it's probably not the best word to describe it. So let me know if there is a better word :)
The statement is not completely exact, because it is valid to have
both 0 non-mutable references and 1 mutable reference. Instead, use
the same wording as in mutability.md.
The doc indicates that you can replace 'before' with 'after' showing the use of try!. The two examples should be equivalent, but they are not.
In the File::create we were inducing a panic before in case of error, not propagating. It is important for newbies (like myself) to understand that try! propagates failures, while unwrap can induce a panic.
The other alternative is to make the 'before' File::create also manually handle Err like the other calls. Either way it would be consistent.
As mentioned in #25893 the copy trait is not very well explained for beginners. There is no clear mention that all primitive types implement the copy trait and there are not a lot of examples.
With this change I try to make it more visible and understandable for new users.
I myself have struggled with this, see [my question on stackoverflow](http://stackoverflow.com/questions/30540419/why-are-booleans-copyable-even-though-the-documentation-doesnt-indicate-that). And I want to make it more transparent for others.
I filed issue #25893 but I thought that I could give it a shot myself to relieve some of the work from the devs :)
If it is not well written or there are some changes to be made before it can be merged, let me know.
Cheers,
Mathieu
Needed to support:
```rust
match X {
pattern if Y ...
}
for pattern in Y {}
```
IMO, this shouldn't require an RFC because it can't interfere with any future language changes (because `pattern if` and `pattern in` are already legal in rust) and can't cause any ambiguity.
In all other places the IDs of link references are without spaces (and explicitly set).
These are just some cleanups I did for the PDF version.
r? @steveklabnik
A few of us [over on the forum](https://users.rust-lang.org/t/string-type-coercion-in-rust/1439) have been tripped up by this distinction, which I don't think is mentioned. It's kind of logical if you read the "Deref coercions" page and squint a bit but I think it would be nice to explain it directly. Here's one way we could clarify it.
"Truth passes, success `panic!`s" seems to be a typo. The closest fix would be something like "Success passes, failure `panic!`s" but to me a "comparison failure" suggests that we couldn't compare the two values at all, not that we could successfully compare them and that the result was non-equality. So I opted to rewrite the paragraph a bit. If there's a better alternative please let me know.
r? @steveklabnik
The paper from which this example was taken made the mistake of assuming
that all five philosophers are men. This is a hypothetical
example--there are no actual philosophers eating spaghetti--so there is
no good reason to make this assumption. Since women make up about half
of the human population, all things being equal, women should represent
about half of the philosophers. However, because this mistake has stood
since 1985, I have changed *all* of the pronouns to be female, to make
up for lost time. If someone would like to revert this patch or switch
to neutral pronouns after 30 years, feel free to set your alarm clock
for 2045.
This adds strictly more information to the source files and reduces the need for customized tooling to render the book. (While this should not change the output of _rustbook_, it is very useful when rendering the sources with external tools like Pandoc.)
This only adds the language marker to "first level" code blocks (and not to code blocks in comments inside of code examples).
r? @steveklabnik
The source code snippet uses `"whatever".as_bytes()` but the compilation error message uses `b"whatever"`. Both should be consistent with each other.
r? @steveklabnik
Minor tweak: the text explaining the Borrow trait talks about slices, but the example immediately following just uses a simple reference; there are no slices involved.
r? @steveklabnik
This adds strictly more information to the source files and reduces the
need for customized tooling to render the book.
(While this should not change the output of _rustbook_, it is very
useful when rendering the sources with external tools like Pandoc.)
Tiny fixes collected while reading through the Rust book. If they're too nitpicky please let me know and I'll ignore the next ones. :)
The spaces after the function and closure arguments might be intentional, but they do not make much sense: the usual formatting doesn't have such spaces, and they aren't helping align the three lines together either.
r? @steveklabnik (as suggested by [CONTRIBUTING.md](https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md))
