Libcore: move "io" to libcore

[kud1ing]

In libcore-land we we can perform calculations and string operations, but we need to discard them eventually, because there are no means to exchange them with the world.

Please move the module "io" to libcore.

[kud1ing]

Once this is moved, we should re-export some "io"-function in "core.rs"
"print", "println" come to mind.

[marijnh]

I disagree. There are various approaches to doing I/O, and hard-wiring one into the core library is probably now what we want.

[kud1ing]

As i understood #1096, one goal of libcore was to provide a prelude so that you can write

fn main() {
   println("hello world");
}

instead of

import std::io;
fn main() {
  io::println("hello world");
}

My assumption is that in the end you are going to do any kind of filehandle based I/O in any case.
Even a pure network-client/-server needs to write to a logfile or to STDERR.

If my assumption is correct, and we don't move "io" to libcore, libcore would never be used without libstd.
So why have libcore at all?

[graydon]

I am in favour of io:: in libcore. We may tweak the interface, and/or add a richer aio one (either in core or std), but that's true of any module we're considering.

I think at least simple, stdio-style synchronous IO is fair by the third (and possibly second) criteria for libcore. Just about every nontrivial program does IO. It's part of the interface exposed by even the narrowest posix-y narrowings of libc's surface, and we even expose bits through our runtime. I think it's appropriate.

[boggle]

I would not go beyond having stdio support and required generic interfaces in core to keep in line with our goal of keeping it small. I could also quite live with keeping io in its own lib atop core but separate from the rest of std if both should turn out big enough to justify this.

An argument against having io in core would be the availability of the log statement which really is enough to get going with any minimal software that only depends on core.