[estebank]

Instead of a large std tied to the stability guarantees of the labguage, I would like to see something akin yo "stdlib distributions", where a versioned set of community libraries can be depended on to interoperate without duplicated deps in your tree. This decoupling would allow Rust to remain 1.X while the equivalent of the stdlib can bump their major version every, lets say, 3 years, without breaking older projects. You'll notice that this is almost the same thing we have today, and anyone could start it just by creating a crate called "my-std" with the list of dependencies they want to provide.

[steveklabnik]

(have an upvote, no idea why you're in the negative)

I have been thinking about this for the past few years, and I think I'd go so far as to make the standard library "not special." That is, make it work similar to the edition system: cargo new would add a dependency for the latest std at the time, build-std would just be transparent, and you treat it like any other crate.

That said, I am sure there are a zillion issues with this today, especially in Rust itself, but if I were to make a Rust++, this is one of the things I'd consider trying to give a shot.

[dureuill]

The issue with this approach lies with the current content of the stdlib: the stdlib is for vocabulary types, that is, types that are meant to be used as interoperability bricks in almost all programs (think Option, Result, Vec).

If you start versioning the stdlib now you need a bridge between the Option from std1.0 and the Option from std2.0. This will become confusing quickly for programs that use libraries that depend on different versions of the std.

We could forbid that situation, but then we have an ecosystem split