Move Read and Write traits into libcore

[bluss]

The traits Read and Write are simple and fundamental (they require and typically use 1 and 2 methods respectively).

It would be nice for the whole ecosystem to provide these in libcore.

Read and Write are at their core simple and non-allocating, both traits should be core compatible.

However, Read has some extension methods that depend on collections -- fn read_to_end(&mut self, &mut Vec<u8>. This is the main obstacle to any simple move from std to core.

I don't have a plan at hand how to achieve this; a core Read and an extension trait in libstd could achieve exactly the same interface, but with the unfortunate fact that it would be a breaking change for some code, for example those implementing Read::read_to_end explicitly.

[bluss]

Write only depends on Result and core::fmt::Arguments, so it should be fine to move. We should take care to not add more extension methods so that this remains true.

[sfackler]

This would be great, but unfortunately, Read and Write depend on io::Error which itself depends on Box: https://github.com/rust-lang/rust/blob/master/src/libstd/io/error.rs#L66-L69

[bluss]

Ugh, I overlooked that completely!

[bluss]

I guess that changes the shape of this issue a bit.

What kind of proto-Read and proto-Write can core provide? Ideally it should seamlessly scale up to full Read / Write with libstd. The error could be an associated type in the core traits.

[sfackler]

An associated error type was discussed as part of the Great IO Overhaul, but ended up being incredibly painful to actually work with IIRC. I can't remember if that discussion was on the original rfc or one of the followups though.

[alexcrichton]

This was actually originally proposed in the I/O reform as it turns out 90% of the adapters and helper methods and such can all live in libcore rather than requiring the standard library. For this to work, however, there were two key assumptions:

• The error type of an I/O operation was an associated type of the Read and Write traits (to sidestep the problem @sfackler pointed out)
• Extra methods like read_to_string were provided via an extension trait in the standard library (this was when "extension traits" were common as we didn't have where Self: Sized).

I made attempts to have an associated error type, and it ended up being very painful to write any amount of generic code over I/O adapters and such. Lots more discussion can be found on the I/O RFCs :)

As a result I don't think we can do this, although there may be perhaps some kernel or subset that could be extracted in the future.

[Ericson2314]

Check out https://github.com/RustOS-Fork-Holding-Ground/coreio! Pull requests adding the various composite readers/writers would be appreciated (@Tobba and I have written things on an as-needed basis).

[bluss]

I am going to close this. A future issue needs a more concrete plan for how to make it work. Thanks!

[Ericson2314]

I should also note that some of composers (e.g. Tee) that were causing so much trouble were deprecated.

Now that the io ship has long said, I believe the best that could be done is place the coreio traits in core, and make a blanket impl from them to the std traits whenever the associated error type can be injected into io::Error (according to From)

[golddranks]

rust-lang/rust#48331 Linking this open issue here, because this thread comes up at Google results while trying to search for the current, open issue.