I’ve been idly wondering if it would be worth introducing entirely new
Write traits, leaving the existing one alone in order to more easily make changes that are tricky to do backward-compatibly. Those changes include soundly reading into an uninitialized slice (cc @Steven Fackler), existing in
libcore (so not requiring
std::io::Error which requires
errno), and perhaps others. These new APIs could live in an
io2 module (
(I am however not volunteering to champion such a proposal.)
That definitely is an option, but it'd be so disruptive that I think we'd need a really good reason to do it. The uninitialized buffer stuff can be added in a pretty clean way to the existing trait so I don't know if it's worth it.
It would indeed be disruptive and probably no individual change alone is worth that. But maybe together?
Having read and write traits in core is a very good thing.
they don't need to be complete replacements for existing read and write though
an ideal situation would be if a subset of current read/write could be extracted and put in a sub trait in core, and then std read and write extend that with all the stuff
and all that would be totally orthogonal to adding new methods for uninit memory or not
an ideal situation would be if a subset of current read/write could be extracted and put in a sub trait in core
But they can’t, because
well, then i guess we'll need io2 eventually
or a merge of core and std
std error needs to be in std because of having os awareness and possible allocating and such, but the point of having core reading and writing is to make your code be totally agnostic to things like that, and even support no OS and no allocation.