Change:
% Guessing Game <del> For our first project, we’ll implement a classic beginner programming problem: the guessing game. Here’s how it works: Our program will generate a random integer between one and a hundred. It will then prompt us to enter a guess. Upon entering our guess, it will tell us if we’re too low or too high. Once we guess correctly, it will congratulate us. Sounds good? </del> <ins> Let’s learn some Rust! For our first project, we’ll implement a classic beginner programming problem: the guessing game. Here’s how it works: Our program will generate a random integer between one and a hundred. It will then prompt us to enter a guess. Upon entering our guess, it will tell us if we’re too low or too high. Once we guess correctly, it will congratulate us. Sounds good? Along the way, we’ll learn a little bit about Rust. The next section, ‘Syntax and Semantics’, will dive deeper into each part. </ins> # Set up

Discussion:
The presence in a Rust source file of unusual but useful kinds of whitespace, such as ASCII 0x0C (form feed), leads to the following error: I have a specific use case for form-feeds in source files. But I think in general it is nice to ignore the same whitespace that every other programming language and file format ignores; it lessens confusion for people coming from other languages and backgrounds. My specific use case is the long-standing, but somewhat uncommon use of the form-feed character (which semantically is a separator between pages of text) as a way to group together especially closely related functions or blocks in a file of source code. Text editors or IDEs such as vim, Emacs or XCode provide convenience features to display these form-feeds in aesthetically pleasing way, move between form-feed-delimited pages, and restrict editing to one form-feed-delimited page at a time. It's just a simple convenience feature, but it would really be nice to support it.
+1, I also use this feature and was disappointed when I found Rust didn't treat it as whitespace.
Looks like a fairly simple change could be made to the lexer so it uses instead of limiting to . The only think I can think of is that the function in has been around since before we had a better function and nobody has changed it since then.
/cc , do we want to accept all kinds of whitespace?
I believe we should, yes.

I just implemented the code in section 3.3 to compare Ruby to Rust. It appears that rustc optimizes away the inner loop of the thread, because I kept increasing the limit and the completion time remained constant. I introduced a simple if statement in the loop, and then I got expected timings. It might be worth modifying the loop so it's not optimized away for a fairer comparison. Here's what I ended up with:
<sighsorry - I thought I was following the link to submit an issue with the Rust Book, but it appears I've submitted an issue to the Rust language proper :(
the book issues are part of the repo here, yes.
Also, I believe that we either 1) did something to fix this, or 2) there's already an issue open, would you mind checking the nightly book and the other issues?
The example in the book still exhibits the "optimized away" problem. I scanned through all the "A-docs" issues and didn't see anything that matched, but I may have missed something.
Sorry, missed "nightly" above - I'll check that...
Nightly appears to be the same as stable - just a simple loop that rustc is smart enough to collapse.
Roger. Thanks for checking, maybe I'm imagining things.