BufRead::is_eof

[stepancheg]

Closes #40745

[rust-highfive]

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

[aturon]

Can you elaborate on the benefits of this function? Seems reasonable, but the libs team is having a hard time imagining where you'd want it.

[stepancheg]

Suppose you have a function which reads a message from a stream:

fn read_one_message(stream: &mut BufRead) -> io::Result<Message> { ... }

And you want to read all the messages from file. If you have is_eof, code could be written like this:

fn read_all_messages(stream: &mut BufRead) -> io::Result<Vec<Message>> {
    let mut r = Vec::new();
    while !stream.is_eof()? {
        r.push(read_one_message(stream)?);
    }
    r
}

read_one_message could return io::Result<Option<Message>> though to use None as signal that EOF is reached.

[alexcrichton]

@stepancheg why would this want to be a trait method though?

The use case there makes sense, but I'm not sure why that means we should add it to the trait.

[stepancheg]

I don't understand. Where else should it be added? Usually only buffered readers can tell if EOF is reached.

If you think function is not that useful, I'm OK with just closing the PR.

[sfackler]

Implementation-wise, this does differ from similar APIs like feof(3), which only reports EOF after that has actually been "reached" through a read.

[alexcrichton]

This was discussed at libs triage recently and the conclusion we reached were:

• The definition of "eof" here is pretty different than other languages' EOF definition (as pointed out by @sfackler)
• This is relatively easy to implement locally (e.g. fill_buf().is_empty())
• It's somewhat semantically odd that this is available only on BufRead, not on Read (which some might expect).

Would it be possible to perhaps rename this method to a more evocative name of what it's doing? The conclusion was that we do not want to land this as is_eof but were open to other names.

[shepmaster]

@stepancheg thank you for the contribution! There's been a suggestion to rename the method, do you think you'll be able to make that change?

[shepmaster]

@stepancheg thank you for the PR but we are going to close this for now since we haven't heard from you in a few weeks. If you have a chance to update this, please feel free to re-open the PR (or ping us if needed).