Rewrite io::BufRead doc examples to better demonstrate behaviors.
#40642
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
frewsxcv
force-pushed
the
io-bufread-doc-examples
branch
from
9c9fa10 to
a09b20b
Compare
|
r? @rust-lang/docs |
src/libstd/io/mod.rs
Outdated
There was a problem hiding this comment.
I'm not a big fan of .unwrap() in examples. Could you replace with .expect() please? Or you could even create a function which returns a Result and use ? operator.
There was a problem hiding this comment.
Since we're using a Cursor though, this will never fail. Should I still use expect? If so, what should the text say?
There was a problem hiding this comment.
In this case add a comment explaining that Cursor will never fail. Both solutions are fine to me.
src/libstd/io/mod.rs
Outdated
Prior to this commit, most of the `BufRead` examples used `StdinLock` to demonstrate how certain `BufRead` methods worked. Using `StdinLock` is not ideal since: * Relying on run-time data means we can't show concrete examples of how these methods work up-front. The user is required to run them in order to see how they behave. * If the user tries to run an example in the playpen, it won't work because the playpen doesn't support user input to stdin.
frewsxcv
force-pushed
the
io-bufread-doc-examples
branch
from
a09b20b to
8fba638
Compare
|
Great, thanks! @bors: r+ rollup |
|
📌 Commit 8fba638 has been approved by |
…=GuillaumeGomez Rewrite `io::BufRead` doc examples to better demonstrate behaviors. Prior to this commit, most of the `BufRead` examples used `StdinLock` to demonstrate how certain `BufRead` methods worked. Using `StdinLock` is not ideal since: * Relying on run-time data means we can't show concrete examples of how these methods work up-front. The user is required to run them in order to see how they behave. * If the user tries to run an example in the playpen, it won't work because the playpen doesn't support user input to stdin.
…=GuillaumeGomez Rewrite `io::BufRead` doc examples to better demonstrate behaviors. Prior to this commit, most of the `BufRead` examples used `StdinLock` to demonstrate how certain `BufRead` methods worked. Using `StdinLock` is not ideal since: * Relying on run-time data means we can't show concrete examples of how these methods work up-front. The user is required to run them in order to see how they behave. * If the user tries to run an example in the playpen, it won't work because the playpen doesn't support user input to stdin.
…=GuillaumeGomez Rewrite `io::BufRead` doc examples to better demonstrate behaviors. Prior to this commit, most of the `BufRead` examples used `StdinLock` to demonstrate how certain `BufRead` methods worked. Using `StdinLock` is not ideal since: * Relying on run-time data means we can't show concrete examples of how these methods work up-front. The user is required to run them in order to see how they behave. * If the user tries to run an example in the playpen, it won't work because the playpen doesn't support user input to stdin.
6 participants
Prior to this commit, most of the
BufReadexamples usedStdinLocktodemonstrate how certain
BufReadmethods worked. UsingStdinLockisnot ideal since:
these methods work up-front. The user is required to run them in order
to see how they behave.
because the playpen doesn't support user input to stdin.