Is the API for BufWriter::into_inner *right*?


#1

BufWriter::into_inner returns Result<W, IntoInnerError<BufWriter<W>>; it returns the error case if flushing the buffer fails.

IntoInnerError<W> has an into_inner method, but this returns the original BufWriter. There is no API to get the inner writer out of a BufWriter if the flush fails, so I’m left with a choice between panicking or retry flushing indefinitely. At very least there should be some force_into_inner method that ignores the flush failure.

IntoInnerError also only implements Debug if W implements Debug, which means you can’t unwrap the result returned by BufWriter in a generic context unless you add a debug bound to your parameter; this seems less than ideal.


#2

It seems reasonable to add a method to take the writer out of the BufWriter (or maybe the error directly?) without flushing.

Once specialization is stabilized, we should be technically able to unconditionally implement Debug for IntoInnerError, though I’m not sure if that kind of thing will actually be conventional or not.


#3

The standard library already uses specialization, so that could be added now.


#4

We have avoided making changes based on specialization that affect the public API, however.


#5

I created buf_redux as an answer to most of my complaints with the buffered I/O APIs in the stdlib. Though, admittedly, most of my focus has been on BufReader and the BufWriter in the crate is mostly unchanged from the version in the stdlib, there is a lot less resistance to making API additions or changes, and I think I’ll go ahead and add the changes you suggested here, as well as put more thought into how to make BufWriter more ergonomic.

Addendum:

buf_redux = "0.5.0" contains the changes I promised. There’s into_inner_with_err() which flushes and unconditionally returns the inner writer as well as the error, if applicable, and then the nightly feature that enables specialized Debug impls so that BufWriter impls Debug even if the inner writer doesn’t.