Change:
/// } /// ``` #[must_use = "`self` will be dropped if the result is not used"] <del> #[unstable(feature = "stdin_forwarders", issue = "87096")] </del> <ins> #[stable(feature = "stdin_forwarders", since = "1.62.0")] </ins> pub fn lines(self) -> Lines<StdinLock<'static>> { self.lock().lines() }

Discussion:
Feature gate: This is a tracking issue for adding new methods that will forward to the corresponding methods on the implementation of . This proposal is related to , and further reduces the obstacles for beginners to write simple interactive terminal programs. Especially for beginners, reading a sequence of lines from the standard input stream can involve intimidating problems with locking and lifetimes. First, the user has to call the free function to get a handle on the stream; then, the user would have to call the method to gain access to the method. At this point, lifetime issues rapidly arise: the following code produces this error: The need to create a binding to the handle seems confusing and frustrating, especially if the program does not need to use the handle again. The explanation is that the lock (and the iterator produced by ) behaves as if it borrows the original handle from , and the temporary value created for the call to the method is dropped at the end of the statement, invalidating the borrow. That explanation might be beyond the current level of understanding of a beginner who simply wants to write an interactive terminal program. Although makes it easier to obtain locked stdio handles, it would be even better if beginners didn't have to deal with the concept of locking at all at early stages of their learning. There is precedent in the forwarder method that implicitly locks and calls the method. However, is somewhat difficult to use, because it requires that the user first allocate a , and it doesn't remove newlines. In contrast, provides an iterator over input lines that removes line endings, including both carriage return (CR) and line feed (LF) characters. The remaining exclusive methods of are less useful to beginners, and require more experience to use. [x] Implementation: [x] Delete forwarder [x] Final comment period (FCP) [ ] Stabilization PR: stabilization, we might want to update existing documentation to recommend these forwarder methods, and include examples of their use. label +A-io +D-newcomer-roadblock
These methods have been around for a while, and they seem reasonable. I think it'd be appropriate to consider stabilizing them. 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] [ ] Concerns: resolved by resolved by 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.
If ended up making work, would we still want these methods?
is an accepted RFC to just make work. I think I would want to check in with the lang team and/or compiler team on an outlook for that before we start adding surface area like this only motivated by working around it. concern better temporary lifetimes
We discussed this API briefly in the libs-api meeting. After another look, I am on board with these methods since the motivation isn't just about working around the way that temporary lifetimes are currently handled &mdash; it's beneficial to be able to iterate lines of stdin without needing to consider that locking needs to be involved. resolve better temporary lifetimes
:bell: This is now entering its final comment period, as per the . :bell:
Two non-strong feelings: it feels a bit odd to stabilize this before The construct indirectly exposes type, which you otherwise can’t observe. I don’t see a way this can be actively problematic though. motivation for stabilizing seems comparatively weaker than motivation for lines. It’s byte-level split, it yields rather than and as such seems like a niche API. Between read_line, lines and split, split wound be the only non-text re-exported API. For a beginner, who might think of stdin as a text stream, which doesn’t split on whitespace, a-la Python, might be confusing.
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.
concern split-is-too-niche Yeah I think there is some concern with here.

If we're adding these routines specifically to work around common use cases, then I'm not sure is one of them in a way that's consistent with the rest of std's APIs (which really wants all text oriented processing to happen inside /). It looks like the FCP is done though, so I'm not sure if registering a concern is possible? I'm just now catching up with stuff after the holidays. Also, these APIs are very poorly documented at the moment. I kind of feel like APIs should have full documentation on them before we consider stabilization. For example, I think these APIs should mention the motivation for their existence, in that it permits more convenient line iteration when compared to having to deal with locking stdin explicitly.
I'm willing to remove the forwarder. Can the API documentation improvement happen during stabilization? There were some API documentation changes that I didn't want to make before stabilization, because I would want higher-level documentation to preferentially mention the forwarder method. My understanding is that we can't do that until during stabilization; is that right?
I'm not opposed to dropping ; seems like the most valuable item here.
Thanks; I'll work on a PR to delete the forwarder.
if someone who's already commented here is interested in reviewing it. maybe ?
For what its worth I've used split for processing input with a non-endline separator, but I agree that the implementation here is probably not the one we want for the sake of consistency. Perhaps the idea would be worth revisiting but behind another feature flag as to not stop the stabilization of the other method.
The removal of is about to be merged; that should address your concern.
resolve split-is-too-niche
:bell: This is now entering its final comment period, as per the . :bell:
Looks like rfcbot is sleeping (: :robot: :mega: The final comment period, with a disposition to merge, as per the , is now complete. As the temporary human substitute for the temporarily unavailable 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.
rfcbot commented earlier (), so I guess it got confused by the concern+resolve after the FCP had "completed".