[Solved] Questions on Library Policy


What is the policy on adding somewhat marginal things to the libraries? By marginal I mean things that are not very often used by run-of-the-mill programmers. Like, for example:

  • Functions for calculations with the rationals? (I know there are some already).
  • Median based statistical methods?
  • Image processing?


Crates.io, the Rust package registry, have all the policies documented here: http://doc.crates.io/policies.html

There are no polices on the contents of the libraries :slight_smile: In general, anything you can build may turn out to be useful for someone else! And a small crate solving very focused problem can made someone’s day. I was over the moon when I’ve found a library for coordinates on the hexagonal grid (https://crates.io/crates/hex2d) during one of the previous ICFP contests :slight_smile:


As Matklad explains, crates.io is the community repository. Everyone is welcome to submit new crates/libraries there, if they believe they could be useful to other people. Small, targeted crates are not a problem. (e.g. md-5, whose only purpose is to provide MD5 hashing)

If you have a small, specific problem with an existing library, most authors react very positive to code contributions. Crates.io in general will have the links to the source code repository if each individual crate/library.
Practically all libraries on crates.io are open source, so you can open issues/bugs and pull requests for code contribution at each crates individual repository.

If you’re talking about the standard library, changes there go through the Rust RFC process. This usually starts with some informal discussion here on these forums to collect opinions. Then somebody (anyone goes, even you and me) writes an RFC (“request for comment”) as an issue in the RFC repository, and discussion continues there.
This more formal process reflects the increased standard for the standard library, which is supposed to maintain API stability for decades


OK, thanks for that information. Would it be a good idea then to put such contributions first into Crates.io and only then maybe start discussions about whether they might be worth promoting into the standard library?


Yep, we generally prefer proposals for addition to the standard library to come from existing and battle-tested crates in the broader ecosystem.


Yup! Rust’s std-lib tries to remain fast, light and nimble. Since it has a great dependency management story thanks to cargo and crates.io, a tiny libstd is not bad.

Even the “futures” crate isn’t in std, even though that’s considered “core primitive” in languages like Java or C#

Rust wants to avoid making a bad decision early in its development, like e.g. java did with their new Date(2017,11,3), which returns 3917-12-03… :disappointed_relieved:
(1900+2017, zero-based month offset, 1-based days…)


It is maintained by the Rust team though, which makes it kind of an in-between of a standard and a community library.