RFC: make the stdlib more hierarchical #9208

huonw · 2013-09-15T11:39:05Z

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

The text was updated successfully, but these errors were encountered:

huonw · 2013-09-15T11:39:39Z

Nominating for backwards compatible.

Kimundi · 2013-09-15T11:52:31Z

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 · 2013-09-15T16:01:56Z

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

alexcrichton · 2013-09-15T17:49:36Z

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 · 2013-09-15T18:15:46Z

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 · 2013-09-15T18:20:45Z

+1 to that, that would be awesome.

catamorphism · 2013-09-19T17:17:24Z

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

New standards have arisen in recent months, mostly for the use of rustpkg, but the main Rust codebase has not been altered to match these new specifications. This changeset rectifies most of these issues. - Renamed the crate source files `src/libX/X.rs` to `lib.rs`, for consistency with current styles; this affects extra, rustc, rustdoc, rustpkg, rustuv, std, syntax. - Renamed `X/X.rs` to `X/mod.rs,` as is now recommended style, for `std::num` and `std::terminfo`. - Shifted `src/libstd/str/ascii.rs` out of the otherwise unused `str` directory, to be consistent with its import path of `std::ascii`; libstd is flat at present so it's more appropriate thus. While this removes some `#[path = "..."]` directives, it does not remove all of them, and leaves certain other inconsistencies, such as `std::u8` et al. which are actually stored in `src/libstd/num/` (one subdirectory down). No quorum has been reached on this issue, so I felt it best to leave them all alone at present. rust-lang#9208 deals with the possibility of making libstd more hierarchical (such as changing the crate to match the current filesystem structure, which would make the module path `std::num::u8`). There is one thing remaining in which this repository is not rustpkg-compliant: rustpkg would have `src/std/` et al. rather than `src/libstd/` et al. I have not endeavoured to change that at this point as it would guarantee prompt bitrot and confusion. A change of that magnitude needs to be discussed first.

New standards have arisen in recent months, mostly for the use of rustpkg, but the main Rust codebase has not been altered to match these new specifications. This changeset rectifies most of these issues. - Renamed the crate source files `src/libX/X.rs` to `lib.rs`, for consistency with current styles; this affects extra, rustc, rustdoc, rustpkg, std, syntax. - Renamed `X/X.rs` to `X/mod.rs,` as is now recommended style, for `std::num` and `std::terminfo`. - Shifted `src/libstd/str/ascii.rs` out of the otherwise unused `str` directory, to be consistent with its import path of `std::ascii`; libstd is flat at present so it's more appropriate thus. While this removes some `#[path = "..."]` directives, it does not remove all of them, and leaves certain other inconsistencies, such as `std::u8` et al. which are actually stored in `src/libstd/num/` (one subdirectory down). No quorum has been reached on this issue, so I felt it best to leave them all alone at present. #9208 deals with the possibility of making libstd more hierarchical (such as changing the crate to match the current filesystem structure, which would make the module path `std::num::u8`). There is one thing remaining in which this repository is not rustpkg-compliant: rustpkg would have `src/std/` et al. rather than `src/libstd/` et al. I have not endeavoured to change that at this point as it would guarantee prompt bitrot and confusion. A change of that magnitude needs to be discussed first.

emberian · 2013-12-15T22:56:39Z

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

alexcrichton · 2013-12-17T20:03:18Z

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 · 2013-12-18T00:40:53Z

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 · 2014-03-23T08:26:26Z

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.

chris-morgan mentioned this issue Oct 29, 2013

Rename files to match current recommendations. #10143

Merged

thestinger closed this as completed Mar 23, 2014

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RFC: make the stdlib more hierarchical #9208

RFC: make the stdlib more hierarchical #9208

huonw commented Sep 15, 2013

huonw commented Sep 15, 2013

Kimundi commented Sep 15, 2013

sfackler commented Sep 15, 2013

alexcrichton commented Sep 15, 2013

bluss commented Sep 15, 2013

alexcrichton commented Sep 15, 2013

catamorphism commented Sep 19, 2013

emberian commented Dec 15, 2013

alexcrichton commented Dec 17, 2013

huonw commented Dec 18, 2013

thestinger commented Mar 23, 2014

RFC: make the stdlib more hierarchical #9208

RFC: make the stdlib more hierarchical #9208

Comments

huonw commented Sep 15, 2013

huonw commented Sep 15, 2013

Kimundi commented Sep 15, 2013

sfackler commented Sep 15, 2013

alexcrichton commented Sep 15, 2013

bluss commented Sep 15, 2013

alexcrichton commented Sep 15, 2013

catamorphism commented Sep 19, 2013

emberian commented Dec 15, 2013

alexcrichton commented Dec 17, 2013

huonw commented Dec 18, 2013

std

Moved

Unchanged

Unsure

extra

Moved

Unchanged

Removed

thestinger commented Mar 23, 2014

`std`

`extra`