Skip to content
Closed
Changes from 3 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
12 changes: 6 additions & 6 deletions src/doc/trpl/looping.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ for (x = 0; x < 10; x++) {
Instead, it looks like this:

```{rust}
for x in range(0, 10) {
for x in (0..10) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The parentheses around 0..10 here are not needed. (Same for line 126 below.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice I did not know that.
However not sure about removing the parens mainly as it allows for easier edits.
The second example

for x in (0..10) {
    if x % 2 == 0 { continue; }
    println!("{}", x);
}

could be refactored to

for x in (0..10).filter(|&x| (x % 2 != 0)) {
    println!("{}", x);
}

where parens become mandatory right?
Keeping the parens saves you from jumping to the begining to add them later.

However if there is a style guide/convention I am breaking let me know and I will make the edit

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK there is no style guide for range literals yet, as they are quite a recent addition. Still, I think that in cases like this, parentheses are just unnecessary noise. The same argument that parentheses make adding methods calls easier could apply to basically any binary operator…

let x = (a + b);
// The parentheses make it easier to change it to this
let x = (a + b).abs();

…but I think that everyone will agree that it’s bad style to put parentheses around every addition operation, and I think this applies to all other operations as well (and thus ..). Also, I don't normally call iterator methods on range iterators because they’re so simple, so I think the case of writing something like (a..b).filter(...) is rare enough anyway to justify a style decision to require parentheses unconditionally.

I also think that because the people who are reading The Rust Programming Language will probably be learning the range notation for the first time, it’s best to show that parentheses are not needed, rather than making them think that they are by using them everywhere.

(Also, if you do end up removing the parens, I just realised you’ll need to update line 41 as well as 21 and 126.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah you make a valid point

println!("{}", x); // x: i32
}
```
Expand All @@ -38,7 +38,7 @@ valid for the loop body. Once the body is over, the next value is fetched from
the iterator, and we loop another time. When there are no more values, the
`for` loop is over.

In our example, `range` is a function that takes a start and an end position,
In our example, the range notation `(0..10)` takes a start and an end position,
and gives an iterator over those values. The upper bound is exclusive, though,
so our loop will print `0` through `9`, not `10`.

Expand All @@ -54,7 +54,7 @@ The other kind of looping construct in Rust is the `while` loop. It looks like
this:

```{rust}
let mut x = 5u; // mut x: uint
let mut x = 5; // mut x: i32
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe these type comments could be preserved? // mut x: i32 for this one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure done.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

realized another pr was merged that made the range(1,10) to 1..10 changes
Only thing is the incorrect type in the comment, if the pr is going to be a complicated merge you can just close it and I can create a new one for it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that might be easiest, yeah. Thanks for your effort! (Feel free to "@huonw" me on the new PR 😄)

let mut done = false; // mut done: bool

while !done {
Expand Down Expand Up @@ -91,7 +91,7 @@ can do with safety and code generation, so you should always prefer
Let's take a look at that `while` loop we had earlier:

```{rust}
let mut x = 5u;
let mut x = 5;
let mut done = false;

while !done {
Expand All @@ -108,7 +108,7 @@ modifying iteration: `break` and `continue`.
In this case, we can write the loop in a better way with `break`:

```{rust}
let mut x = 5u;
let mut x = 5;

loop {
x += x - 3;
Expand All @@ -123,7 +123,7 @@ We now loop forever with `loop` and use `break` to break out early.
iteration. This will only print the odd numbers:

```{rust}
for x in range(0, 10) {
for x in (0..10) {
if x % 2 == 0 { continue; }

println!("{}", x);
Expand Down