RFC: make the stdlib more hierarchical

[huonw]

Rust has a module system and so it seems like a waste to just export everything as std::foo and extra::foo: grep '^pub mod' | wc -l counts 53 and 50 direct exports respectively.

Low hanging fruit would be moving std::{i8,uint,f32, ...} to std::num::*.

Other possibilities (off the top of my head):

• std:
  • ascii, c_str to str::* or even ascii, c_str, to_str, from_str, str, fmt to std::text::* (or anything in between)
  • hashmap, trie, vec, at_vec to container::*
  • at_vec to vec::at_vec (or container as above)
  • ptr, owned, managed, borrow to ptr::* (with the current ptr becoming ptr::raw.)
• extra:
  • bigint, rational, complex to num::*
  • dlist, list, ringbuf, smallintmap, priority_queue, treemap to container::*
  • sha1, sha2, md5, md4 to crypto::* (or something, I'd feel bad about putting md5/md4 in "crypto")

(I imagine it'd be very easy to get carried away with making it too granular.)

[huonw]

Nominating for backwards compatible.

[Kimundi]

1+, we don't need to get a complicated/detailed module hierarchy in the std lib, but something better than a flat list would definitely improve organisation and make related things easier to find.

std::text seems like a general enough module name, encodings can also live in there.

---

Using modules would also mean the source files could get properly grouped in directories without needing the #[path = "..."] attribute to make rustc find them.

[sfackler]

There was some discussion of reorganizing the various encoding modules in extra at #8310.

[alexcrichton]

One thing we'd want to watch out for is making common types difficult to access, having to type use std::containers::hashmap::HashMap is a lot of characters just to get a normal hash map in scope.

I'm all for reorganization though if it collects things together nicely.

[bluss]

modules like hashmap, trie and extra::treemap don't seem to have any toplevel pub fn or other items that are commonly accessed(?). Maybe the types can be imported so they are all available under std::container::{HashMap, HashSet, TrieMap, TreeMap} (is this too inconsistent?)

[alexcrichton]

+1 to that, that would be awesome.

[catamorphism]

accepted backwards-compatible (we're not committing to doing this; just, the decision is on milestone 2)

[emberian]

+1, with @blake2-ppc's idea.

[alexcrichton]

It was decided in today's meeting that we are in favor of moving in this direction, but it is difficult to say "yes" or "no" in a general context without a concrete proposal. One specific thing that we dislike today is std::rc::Rc, std::hashmap::HashMap and how you always repeat yourself when importing types. It was brought up that some crates in servo solve this through re-exports.

[huonw]

Proposal:

std

Moved

• text
  • ascii
  • c_str
  • char
  • str
  • fmt
  • to_str, from_str
  • send_str
• num
  • u8, u16 etc.
  • cmath
• ptr
  • reexporting rc::Rc, gc::Gc
  • rc
  • raw
  • owned
  • borrowed
  • managed (irrelevant when @ gets removed)
  • gc
• container
  • reexporting the top-level containers (i.e. HashMap, HashSet, Trie, etc.)
  • hashmap
  • trie
  • vec
    • at_vec (irrelevant when @[] gets removed)

Unchanged

• any
• bool
• cast
• cmp
• condition
• hash
• io
• iter
• libc
• mem
• os
• path
• prelude
• rand
• reflect
• repr
• rt
• run
• to_bytes
• util (slated for removal, anyway?)

Unsure

• comm, local_data and task could be come task::{comm, local_data}, or concurrent::{comm, local_data, task} (with appropriate re-exports)
• cell, option, result, either are all "containers" of some sort, they could be placed in container, or also just left unchanged.

extra

This may be infeasible, if we end up splitting extra, although it might create good lines along which to split it.

Moved

• num
  • bigint
  • complex
  • rational
• container
  • bitv
  • btree
  • c_vec
  • dlist
  • enum_set
  • list
  • lru_cache
  • priority_queue
  • ringbuf
  • smallintmap
  • treemap
• encoding (I'm personally not keen on this name, and not 100% sure that this division is reasonable)
  • serialize
  • json
  • ebml
  • base64
  • hex
• term
  • terminfo
• concurrent
  • reexporting Arc, MutexArc, RWArc, Future
  • arc
  • future
  • sync
  • task_pool

Unchanged

• arena
• flate
• getopts
• glob
• semver
• stats
• tempfile
• time
• url
• uuid
• workcache

Removed

• sort, should just be one or two functions in vec (add a fast O(n log n) stable sort without Clone to std::vec #9819)

[thestinger]

This has essentially happened with the splitting up of the various crates. I think the conversation here is too out-of-date to still be relevant, although similar changes could be proposed for other parts of the standard library.