Continuing the discussion from The Life and Death of an API:
The Python standard library is sometimes said to be where modules go to die, as improvements to it can take 1 to 2 years to be released. Rust is better with 6~12 weeks from landing a PR to a stable release, but that’s still nowhere the flexibility of
cargo publish. Additionally, moving into the standard library means you have to make strong stability promises: no breaking change until we increment the major version number for the entire language, which hopefully will be very rare.
Any advantage to moving into
std needs to outweigh these downsides.
So what are reasons to add some new feature in the standard library? I can think of:
- It can not reasonably be done outside. For example adding a method to a standard library types that need access to private fields.
- It offers interfaces that should be “standardized” to make it easier for unrelated libraries to interoperate with each other. Things like the
- Some people don’t like having dependencies.
- Curation: being included is a sign of quality and scrutiny, whereas I have no idea how good is a library I just found on crates.io
In my opinion, respectively:
- Simpler low-level functionality like
Vec::from_raw_partsthat enable building complex stuff externally should be preferred over including the complex stuff.
- The bar should be very high for this IMO, and possibly require some experimentation time on crates.io
- Cargo makes dependencies easy enough that this argument is invalid. (If it doesn’t yet, Cargo should be improved.)
- I think this reason is just not good enough: there are other ways to do this. Having crates in the rust-lang github org could be one of them. (But perhaps creates an undesirable “us versus them” division.)