-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Add has_data_left() to BufRead #85815
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
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @m-ou-se (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. |
/// } | ||
/// ``` | ||
#[unstable(feature = "buf_read_has_data_left", reason = "recently added", issue = "40745")] | ||
fn has_data_left(&mut self) -> Result<bool> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
has_remaining_data
seems less... informal?
Is there a reason to check the negative case, i.e. it being not empty as opposed to the is_empty
that can be found on many other things?
Also, what's the benefit of this method if it requires error handling? If you have to do error handling anyway you might as well do, that way you only need to do error handling once instead of doing it in the loop condition and when reading the line.
let mut line = String::new();
loop {
match std.read_line(&mut line) {
Ok(0) => break, // eof
Ok(_) => {
// do something with line
},
Err(e) => panic!("read error {}", e);
}
line.clear()
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just couldn't think of a good name for the positive case, but I'm open for suggestions.
As for the benefits, the main use case I have for this is for things like deserializing object directly from a file in a loop. The deserialization function will return an error if it encounters an EOF, and depending on the Serde library it's not always easy to tell whether the error is caused by EOF. It's easier to check for EOF separately in the loop condition.
while file.has_data_left()? {
let obj = rmp_serde::decode::from_read(&mut file)?;
// rest of the loop
}
As shown above, the additional error handling isn't really a big deal when using question mark syntax (or just unwrapping).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does that really solve the stated problem though? serde could still encounter an EOF in the middle of parsing an input.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If serde encounters an EOF in the middle of deserializing an object then it's a syntax error and the input is invalid, at least for that object. If serde finishes parsing the last object in a valid input then all that's left in the reader would be EOF. In that case having EOF checking would prevent serde from attempting to deserialize another object and throwing a syntax error. Having EOF checking between deserialize calls allows the loop to end gracefully when encountering EOF in a valid input.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your PR!
This looks reasonable to me. We can think a bit more about the name (is_finished
, reached_end
, has_remaining_data
, ...?), but we can add it now as unstable as is, and have that discussion before we stabilize it.
library/std/src/io/mod.rs
Outdated
/// println!("{:?}", line); | ||
/// } | ||
/// ``` | ||
#[unstable(feature = "buf_read_has_data_left", reason = "recently added", issue = "40745")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you open a new tracking issue for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tracking issue here (#86423)
@bors r+ |
📌 Commit 99939c4 has been approved by |
☀️ Test successful - checks-actions |
Add has_data_left() to BufRead This is a continuation of rust-lang#40747 and also addresses rust-lang#40745. The problem with the previous PR was that it had "eof" in its method name. This PR uses a more descriptive method name, but I'm open to changing it.
This is a continuation of #40747 and also addresses #40745. The problem with the previous PR was that it had "eof" in its method name. This PR uses a more descriptive method name, but I'm open to changing it.