[rust-dev] criteria for core lib

Graydon Hoare graydon at mozilla.com
Fri Dec 2 10:48:36 PST 2011


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?)


More information about the Rust-dev mailing list