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

The naming of BufReader/BufWriter and MemReader/MemWriter is confusing #12498

Closed
mneumann opened this issue Feb 23, 2014 · 3 comments
Closed

Comments

@mneumann
Copy link
Contributor

It is unclear that MemReader operates on an owned vector while BufReader on a borrowed vector. For the reader I think there is no difference between a MemReader and a BufReader. MemReader::new([1u8]) can be replaced by BufReader::new([1u8].as_slice()). Only the MemWriter and BufWriter differ in that MemWriter can grow the buffer.

How about this naming: BufReader, BufWriter, GrowableBufWriter?

@steveklabnik
Copy link
Member

/cc @aturon

@aturon
Copy link
Member

aturon commented Jan 23, 2015

This will be resolved during io reform.

@alexcrichton
Copy link
Member

These have all been fixed with the new Cursor type.

matthiaskrgr pushed a commit to matthiaskrgr/rust that referenced this issue Mar 21, 2024
[`map_entry`]: call the visitor on the local's `else` block

Fixes rust-lang#12489

The lint already has all the logic it needs for figuring out if it can or can't suggest a closure if it sees control flow expressions like `break` or `continue`, but it was ignoring the local's else block, which meant that it didn't see the `return None;` in a `let..else`.

changelog: [`map_entry`]: suggest `if let` instead of a closure when `return` expressions exist in the else block of a `let..else`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants