Change:
Feature gate: This is a tracking issue for the function. The equivalent of , but generalized to all impls. As the documentation on says, the advantage of this function is that it means you don't have to create a variable first and it provides more type safety since you can only get the buffer out if there were no errors. If you use , you have to remember to check whether the read succeeded because otherwise your buffer will be empty. It's friendlier to newcomers and better in most cases to use an explicit return value instead of an out parameter. <!-- For most library features, it'd be useful to include a summarized version of the public API. (E.g. just the public function signatures without their doc comments or implementation.) --<!-- In the simplest case, this is a PR implementing the feature followed by a PR that stabilises the feature. However it's not uncommon for the feature to be changed before stabilization. For larger features, the implementation could be split up in multiple steps. --- [x] Implementation: [x] FCP [x] Stabilization PR () <!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- [x] Function signature ()
What is the status on stabilizing this addition to the library?
/ Can we start an FCP?
Thinking a bit about the signature: Considering is already implemented for , shouldn't this function just take an instead of ?
I modeled it after , which takes an , but that has to use because it's defined as part of the trait. I don't know enough about the idiom for here, so if that works, it seems okay to me.
I'm working on a related PR to have enlarge the string buffer before reading to accommodate the full file size. A nice side effect is that it will make more performant when the reader is a file. If it lands do you think there's anything in that should be updated?
That's great; thanks for working on this! Perhaps we could add another paragraph at the end like this:
Done.
It seems like should be paired with a method to match the other pairings in the standard library: Would it be or ? I'd say to match the trait since the reader might not be at the beginning.
Now that the PR to remove the from the signature is in the merge queue, should a stabilization FCP be proposed?
I will open a stabilization PR next week or so.
Actually, I think a libs team FCP needs to be completed first. could you kick that off? (Or do I need to do something before that?)
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.

Discussion:
/// # Examples /// /// ```no_run <del> /// #![feature(io_read_to_string)] /// </del> /// # use std::io; /// fn main() -> io::Result<()> { ///     let stdin = io::read_to_string(io::stdin())?;

///     Ok(()) /// } /// ``` <del> #[unstable(feature = "io_read_to_string", issue = "80218")] </del> <ins> #[stable(feature = "io_read_to_string", since = "CURRENT_RUSTC_VERSION")] </ins> pub fn read_to_string<R: Read>(mut reader: R) -> Result<String> { let mut buf = String::new(); reader.read_to_string(&mut buf)?;