Guide: Standard input

[steveklabnik]

No description provided.

[crackofdusk]

Shouldn't this be:

.ok().expect("Failed to read line");

?

[steveklabnik]

Yes. I will fix that soon. Damn ruby. :)

[mdinger]

I know you're trying to keep it simple until later but I think a few more details here would be helpful. I thought this was puzzling. Too few details and the user will modify something and confuse themselves without recourse.

So Rust expects us to handle this case.

What you mean by this is unclear. Rust expected us to handle it; what if we don't? Will it crash? Will Rust refuse compilation?

Why tell it ok()? Why not just go directly to expect(). If ok() is to tell Rust everything is gonna be fine, when it fails then we lied (it wasn't ok()). How did ok() help?

Also, see below:

// I'll remove the error handling to see what happens...
// Should this compile because some case wasn't handled? Apparently it does...
let input = io::stdin().read_line(); // `Ok(test)` instead of `test`...
let input = io::stdin().read_line().ok(); // `Some(test)`...
// Rereads explanation and is more confused about `Ok` and `Some`

Here's a different type of explanation (hopefully sorta accurate):

Rust will encapsulate the input as protection against possible errors. The user must remove this layer in order to use it. ok() transfers the data from a one wrapper to another wrapper (why? I don't know) so that errors can be handled properly. expect() removes the layer except during errors. During an error, it shows the message it was given.

Not advocating my wording. I just wanted to give a possible example so it wasn't just a complaint.

[EDIT] Moved comment to diff instead of on file

[steveklabnik]

Right. There's a balance that needs struck here: this stuff requires concepts we don't have yet. I don't want to have to fully explain IoResult, etc. That said, the explanation may not be enough.

[mdinger]

Another option is to explicitly defer it:

// Cheap error handling which is quite complicated and
// will not be explained until Section 7.4
// Basically, use normally and call "Error!" when it errors
.ok().expect("Error!");

Accelerated C++ does that often and I find it really helpful. They never lie, they explain enough for the section, and they tell you where to look if you want more info (will be easier to link when the guides finished though...). Accelerated C++ is quite terse and dry probably though.

Examples:

Its [<< in cout << "Hi"] right operand is a string literal, which has a mysterious type that we shall not even discuss until pg. 176
--- Accelerated C++ pg. 4

The type of a string literal [compared with a character literal] is much more complicated and we shall not explain it until pg. 176.
--- Accelerated C++ pg. 14

The details of [istream] turn out to be complicated enough that we won't discuss it in detail until pg. 222
--- Accelerated C++ pg. 40