Skip to content
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

Add lines_any to BufRead (mirroring str) #1188

Closed
RalfJung opened this issue Jul 2, 2015 · 3 comments
Closed

Add lines_any to BufRead (mirroring str) #1188

RalfJung opened this issue Jul 2, 2015 · 3 comments
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.

Comments

@RalfJung
Copy link
Member

RalfJung commented Jul 2, 2015

Currently, both str and BufRead provide a function lines() to iterate over lines as separated by \n. str also provides lines_any() to recognize both \n and \r\n as line separator. This is very useful, e.g. to iterate over the lines of stdin and get the same behavior across platforms. Hence I think BufRead should have lines_any() as well.

I'm currently trying to implement this myself.

Note: I think it would be even better if lines() properly recognized both kinds of line-endings. That's certainly the more common operation. I can hardly imagine a good reason for wanting to split only some kinds of lines - and if one needs that, a generic "split at this byte" would have "split at \n" as an instance.
Would it violate Rust's compatibility promise to change lines() to properly recognize both kinds of line endings?

@nrc nrc added the T-libs-api Relevant to the library API team, which will review and decide on the RFC. label Aug 29, 2016
@mbrubeck
Copy link
Contributor

Fixed by #1212.

@glaebhoerl
Copy link
Contributor

(Did you want to close as well?)

@mbrubeck
Copy link
Contributor

Yes, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants