-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Implement BufReader #8934
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
Implement BufReader #8934
Conversation
Hmm, I'm actually curious why we have That being said, even with both Anyway, I'm curious what @brson has to say about the status of these apis. It seems to me that |
Since struct MemReader<'self> {
buf: ~[u8],
reader: MemReader<'self>
} is possible since it can't (I think) be constructed such that the lifetimes work out. After construction, it couldn't be moved. We could use a macro to create the implementations. I agree that The other weird thing in here is that everything implements |
Oh well that's unfortunate, I hadn't thought of that. I actually suppose that with destructors it may not even be sound to have something like that. Regardless, it looks to be that the code is very similar between I don't really see why we can't implement seek on these buffers. It should be pretty simple, right? I think that it's currently failing just because it's not implemented yet. |
Now that I think about it, |
I suppose they do all have their uses. Code duplication is sad though :( |
I don't have a particularly strong opinion on how these should be designed, as long as all the use cases are covered. |
Thanks for the I/O improvements. |
add [`as_underscore`] lint closes rust-lang#8847 detect usage of `as _` and enforce the usage of explicit type like ```rust fn foo(n: usize) {} let n: u16 = 256; foo(n as _); ``` will suggest to change to ```rust fn foo(n: usize) {} let n: u16 = 256; foo(n as usize); ``` changelog: add [`as_underscore`] lint
No description provided.