Amend I/O reform RFC to address issues with flush

[mzabaluev]

No description provided.

[glaebhoerl]

Writer doesn't really get any smaller - all of the same methods are still there - just refactored.

[jmesmon]

note that this is an edit of a previous RFC which removed quite a few methods from Write. The statement you're commenting was preserved from that one.

[alexcrichton]

After taking another look at the implementations, I don't think that this "deep flushing" is happening (at least not in std::io), perhaps this was just a problem in old_io?

[mzabaluev]

Indeed, it's just that the documentation is vague.

[alexcrichton]

After thinking about this a bit today, I'm not quite sure that we may want the split. I agree that other abstractions may want a flush method as well, but I'm not sure that this incarnation of Flush is appropriate for all use cases. My biggest concern is that the usage of io::Error may make it inadequate for the general use case. For example std::fmt::Write uses a different error type than I/O. Additionally, delegation of a flush method from one trait to another (if the flush method is duplicated among traits) arguably takes fewer lines to express than an explicit implementation of Flush itself.

I feel like there may be a place for a generic Flush, but I don't find the motivation compelling enough to try to introduce the general trait at this time.

[alexcrichton]

cc @aturon

[lilyball]

I'm not sure what the use-case of a generic Flush is. I can't think of any reason why a function or type would want to be able to flush() a stream without first having written something to it, and if it knows how to write to the stream then it obviously knows what type the stream is (and therefore is already bound on something like Write).

I also don't see what the benefit is of moving the declaration of fn flush(&mut self) -> io::Result<()> out of the Write trait and into a separate trait. Given the hypothetical TextWriter, having both Write and TextWriter declare fn flush(&mut self) -> io::Result<()> is not code duplication in any meaningful sense. Any implementation of these traits would need to implement flush() regardless of where it's declared, and the fact that both Write and TextWritermay want to have an identical methodfn flush(&mut self) -> io::Result<()>` does not necessarily mean that this is in fact a truly generic flush method that is appropriate for all stream types.

In fact, the only benefit that comes to mind is a type that implements both Write and this hypothetical TextWriter would only need to implement flush() once, instead of twice. But that seems like an edge case that's not worth worrying about, and it's also not necessarily obvious that the implementation would even want to be the same in both cases (I can think of some esoteric stream types that might want the ability to have flushing behavior that differs from Write::flush).

[mzabaluev]

@alexcrichton:

For example std::fmt::Write uses a different error type than I/O.

There is actually a related issue of its own: std::fmt::Error should expose std::io::Error as a possible cause.

[mzabaluev]

I have filed issue rust-lang/rust#23386 to correct the documentation of into_inner, and #978 to amend the I/O RFC accordingly.
As the generic Flush trait did not get much support, I'm closing this PR.