There is a number of issues with new
std::io which have been discussed here and elsewhere, but didn’t get a dedicated thread. I’ll try to round them up here.
There must be a
closeoperation on types backed by POSIX file descriptors to be able to prevent silent data loss after writing (there’s nothing a program can do about the descriptor after failed
close, but it must be possible to observe the error). RFC PR #770 has some suggestions; I disagree with the idea of making it a part of
Write, but there may be a need for some trait-based solution as well. It’s also not clear what to do when dropping the object in case
closewas not called; there is talk of RAII guards, but I don’t think blocking calls and the RAII pattern mix well.
The contract of
flushdoes not fit all use cases. It’s specified as a top-to-bottom flush, but methods like
into_inneron composed writers call it before returning the underlying writer that you may want to continue writing to. It may be preferred in some cases (e.g. stateful encoding writers) to only finalize output on the topmost layer.
Writetrait mixes two different concerns. It’s a trait for byte-oriented output, but it is also the trait that provides
flush. There is a need for output traits specialized to certain data types, most notably UTF-8 character output. Those may need
flushas well, but adding
flushto each of them looks like silly duplication. It seems prudent to separate
flush(or a pair of “shallow” and “deep” flush methods as proposed above) into its own trait that
Writeand similar traits would require.
I’d like to get some thought on these issues before coming up with an RFC detailing solutions.