Libcore: move "io" to libcore #1373

Closed
kud1ing opened this Issue Dec 22, 2011 · 5 comments

4 participants

@kud1ing
kud1ing commented Dec 22, 2011

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
kud1ing commented Dec 22, 2011

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

@marijnh
Contributor
marijnh commented Dec 22, 2011

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
kud1ing commented Dec 22, 2011

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?

@kud1ing kud1ing closed this Dec 22, 2011
@kud1ing kud1ing reopened this Dec 22, 2011
@graydon
Contributor
graydon commented Dec 23, 2011

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
Contributor
boggle commented Dec 25, 2011

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.

@graydon graydon was assigned Jan 31, 2012
@graydon graydon closed this in d91ec3c Mar 12, 2012
@graydon graydon added a commit to graydon/rust that referenced this issue Mar 13, 2012
@graydon graydon Libc/os/run/rand/io reorganization. Close #1373. Close #1638.
 - Move io, run and rand to core.
 - Remove incorrect ctypes module (use libc).
 - Remove os-specific modules for os and fs.
 - Split fs between core::path and core::os.
6f5853f
@graydon graydon was unassigned by kud1ing Jun 16, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment