BufWriter should buffer up to its capacity

[Lucretiel]

rust/src/libstd/io/buffered.rs

Line 662 in eeaf497

if buf.len() >= self.buf.capacity() {

Suppose you had a BufWriter with capacity 4. If you write b"1234" to it, that will be flushed directly to the underlying stream, but if you write b"12" and then b"34", those will be buffered. The unit tests confirm this behavior, but it seems surprising to me.

[Amanieu]

I don't think we make any guarantees on the exact buffering behavior other than "some buffering happens". In this particular case, copying the data to the buffer is pointless since we'll need to flush the buffer on the next write call anyways: it doesn't help to reduce the number of underlying write calls.

[m-ou-se]

I think the current implementation makes sense. I'd say the goal of a BufWriter to reduce the number of write calls on the underlying stream. Buffering a write call of the full buffer capacity only serves the purpose of using the buffer as much as possible, as the number of write calls (and their sizes) remain the same. That doesn't seem useful to me.

[m-ou-se]

Maybe instead, writing "12" and then "34" into a BufWriter with a capacity of 4 should flush right after the "34", instead of waiting until the next call. Feels slightly more consistent.

[Lucretiel]

I'm actually working on a PR that does something similar to that. The issue you run into, at least for write, is that you have to report either success or an error, and the latter case implies that 0 bytes were written. So if you buffer "34", you have to report Ok(2), which means you don't want to try any additional fallible io operations. However, the story is a bit different for write_all, and I think there's still an opportunity for optimization where, you split incoming slices in order to make them fit in the tail of the local buffer, to reduce the overall number of writes.

In any case, I've been convinced about the reasoning for this, so this issue is satisfied.