Hi,

I'm in the process of adding a 'core' lib that will complement std in the following fashion:

  - core will be automatically 'use'd in any crate, unless you ask for
    --no-core when running the compiler.

  - everything in core will be automatically imported into the crate
    you're building, again, unless you pass --no-core

The idea here is that some "library" code is so universal as to be not worth burdening every user with writing "use std;" and -lstd with every time they build a program, and that as libstd grows, the tension to "not have to link or distribute libstd" for small/simple programs grows stronger. Nobody wants a static-linked "hello world" to be 10mb.

The interesting question is: what are the criteria for something to be in 'core' vs. 'std'? I've been thinking of the following criteria:

  - If it's a module that relates 1:1 with a built-in tycon, it goes
    in core. This means u8, u32, ..., str, vec, all go in core.

  - If it's a module that relates 1:1 with a built-in runtime service,
    it also goes in core. This means task, comm, os, fs, sys, dbg, rand,
    unsafe, test, time, uv, run_program all go in core.

  - If it's a module that covers a type we wind up using "in nearly
    every nontrivial program", it goes in core. This means option,
    either, result and extfmt go in core.

This is quite a bit of the stdlib, but not all. It leaves:

bitv, cmath, ctypes, c_vec, deque, ebml, four, fun_treemap, getopts, json, list, map, net, rope, sha1, smallintmap, sort, tempfile, term, treemap, tri, ufind, unicode, util

all in std. And as we add more stdlib stuff over time (I think I'd prefer a big libstd -- see https://github.com/graydon/rust/wiki/Standard-library-notes) we will be making std larger, and core not-much-larger, possibly even smaller as we reimplement rt stuff in rust code.

Are these agreeable criteria? Do you want fewer or more modules in core?

(Alternatively: Do you think this is a terrible idea? Do you want to restart the conversation about large-vs-small libstd?)

-Graydon
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to