Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve grammar in a few sections #1305

Merged
merged 2 commits into from
Feb 3, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 7 additions & 8 deletions src/flow_control/for.md
Original file line number Diff line number Diff line change
Expand Up @@ -49,14 +49,13 @@ fn main() {
## for and iterators

The `for in` construct is able to interact with an `Iterator` in several ways.
As discussed in with the [Iterator][iter] trait, if not specified, the `for`
loop will apply the `into_iter` function on the collection provided to convert
the collection into an iterator. This is not the only means to convert a
collection into an iterator however, the other functions available include
`iter` and `iter_mut`.

These 3 functions will return different views of the data within your
collection.
As discussed in the section on the [Iterator][iter] trait, by default the `for`
loop will apply the `into_iter` function to the collection. However, this is
not the only means of converting collections into iterators.

`into_iter`, `iter` and `iter_mut` all handle the conversion of a collection
into an iterator in different ways, by providing different views on the data
within.

* `iter` - This borrows each element of the collection through each iteration.
Thus leaving the collection untouched and available for reuse after the loop.
Expand Down
2 changes: 1 addition & 1 deletion src/flow_control/if_let.md
Original file line number Diff line number Diff line change
Expand Up @@ -99,7 +99,7 @@ fn main() {
}
```

Another benefit: `if let` allows to match enum non-parameterized variants, even if the enum doesn't `#[derive(PartialEq)]`, neither we implement `PartialEq` for it. In such case, classic `if Foo::Bar==a` fails, because instances of such enum are not comparable for equality. However, `if let` works.
Another benefit is that `if let` allows us to match non-parameterized enum variants. This is true even in cases where the enum doesn't implement or derive `PartialEq`. In such cases `if Foo::Bar == a` would fail to compile, because instances of the enum cannot be equated, however `if let` will continue to work.

Would you like a challenge? Fix the following example to use `if let`:

Expand Down