Make io::stdout() and io::stderr() return buffered writers by default #12630
Conversation
There was a problem hiding this comment.
What is the reason for wrapping the writer in Option? As near as I can tell, it will always be a Some.
There was a problem hiding this comment.
You can't move out of an object that has a destructor, so in order to support the unwrap() method this needs an Option
There was a problem hiding this comment.
Oh. I didn't actually realize that. I guess that makes sense, as the destructor would need to be able to figure out that the field had been moved.
It's still not entirely clear what should happen if there was an error when flushing, but I'm deferring that decision to rust-lang#12628. I believe that it's crucial for the usefulness of buffered writers to be able to flush on drop. It's just too easy to forget to flush them in small one-off use cases. cc rust-lang#12628
Similarly to rust-lang#12422 which made stdin buffered by default, this commit makes the output streams also buffered by default. Now that buffered writers will flush their contents when they are dropped, I don't believe that there's no reason why the output shouldn't be buffered by default, which is what you want in 90% of cases. As with stdin, there are new stdout_raw() and stderr_raw() functions to get unbuffered streams to stdout/stderr.
Now that we can call `flush()` in destructors, I think that it's appropriate for stdout/stderr to return buffered writers by default. This doesn't enable certain functionality like a buffered stdin does, but it's what you want 90% of the time for performance reasons.
|
This is a driveby comment from someone with no real stake, so please give it only as much thought as it deserves, which is not much: It might make sense for stderr to be unbuffered by default. This is the case in Perl, Python, Ruby, and C, and probably other languages (those are the only ones I checked.) I'm sure there are good reasons for this beyond the ones I will list here, but mine are: In the event of a crash, you want to have the most up-to-date output from stderr, and unlike stdout you typically aren't ever sending huge volumes of data through stderr in a potentially performance-critical way (such that default-buffering is beneficial enough to outweigh the surprise it causes.) |
…ng-pat, r=Veykril fix: infer byte string pattern as `&[u8]` when matched against slices Fixes rust-lang#12630 c.f. [rustc_typeck](https://github.com/rust-lang/rust/blob/1603a70f82240ba2d27f72f964e36614d7620ad3/compiler/rustc_typeck/src/check/pat.rs#L388-L404)
Correct parentheses for [`needless_borrow`] suggestion This fixes rust-lang#12268 Clippy no longer adds unnecessary parentheses in suggestions when the expression is part of a tuple. --- changelog: Fix [`needless_borrow`] unnecessary parentheses in suggestion.
4 participants
Now that we can call
flush()in destructors, I think that it's appropriate for stdout/stderr to return buffered writers by default.This doesn't enable certain functionality like a buffered stdin does, but it's what you want 90% of the time for performance reasons.