Consider moving parts of libstd::io to libcore

[erickt]

A decent chunk of libstd::io looks like it could be moved over to libcore, which would be really handy for low level systems. While this would ultimately be convenient, there'd be some transitional pain making this move. The biggest source would be that'd we'd have to parameterize the Reader/Writer types on the error. We'd also have to convert a couple of the default methods over into generic functions to make this work.

Here are the things that I believe could be moved over:

• Without modification:
  • RefReader, Writer, RefWriter, Stream, Buffer, Seek, Listener, Acceptor, IncomingConnection
  • All of std::io::extensions
  • std::io::mem::BufWriter and std::io::mem::BufReader
  • std::io::util::LimitReader, std::io::util::NullWriter, std::io::util::ZeroReader, std::io::util::NullReader, std::io::util::ChainedReader, std::io::util::TeeReader, std::io::util::IterReader.

With some modification:

• Reader and Buffer with these methods converted into generic functions:
  • Reader::push, Reader::push_at_least, Reader::read_exact, Reader::read_to_end, and Reader::read_to_string, Buffer::read_line, Buffer::read_until
• We could also move FileMode, FileAccess, FileType, FileStat, and UnstableFileStat, but it might be better to leave os-specific stuff in libstd.

There are a couple that we could probably rewrite to not use things like Vec, such as std::io::util::MultiWriter.

[huonw]

If we had trait Writer<E> { ... } in core::io, std::io could then reexport pub type Writer = core::io::Writer<IoError> (if/when that works nicely), in a similar manner to @alexcrichton's idea to have collections::HashMap<K, V, Hasher> with pub type HashMap<K, V> = collections::HashMap<K, V, RandomisedSipHasher> in std::collections.

I think this would make the majority of the change user-invisible.

[alexcrichton]

I have toyed with the idea of moving std::io into core or another library underneath the standard library in the past, but I've always ended up having to bend over too far to get everything to work out.

One of the major problems I am unsure of how to deal with is IoError. We could take a generic approach that @huonw laid out, but that would require language changes I don't believe are in place.

In general, I've been wary about having a core::io module because I/O isn't necessarily incredibly core to the rust language itself, but it would certainly be useful to replace traits such as FormatWriter and hash::Writer!

[alexcrichton]

My personal opinion is that having the reader/writer traits parameterized by an error is a non-starter. Using the encodable/decodable traits are quite painful to have to have an extra type parameter all over the place, and the reader/writer traits are even more common. To make a change such as that I would rather wait for something like associated items or the typedef that @huonw mentioned.

[steveklabnik]

The IO reform RFC should be taking care of this now.