I've seen this said many times, but I don't really understand why.
Why couldn't a new Rust edition create a new std2021 (for instance), and automagically use it when importing a std submodule in a project using the new edition (and in the prelude)? The old implementation would still be imported using std in crates using prior edition, and could still be imported in the new edition, but named std2018.
If all the implementation (except the now deleted stuff) is put in the std2021 module and the old std2018 () simply re-export it (and re-implement the old stuff), you wouldn't break anything would you?
I'm probably missing something, but so far I don't know what and I'd be really happy if somebody enlightened me.
There may be possible ways of doing this, but you're approaching this from the wrong angle. Right now, this is not possible, due to policy. This policy is informed by the technical restrictions right now. There may be possible ways in the future to handle this, but as of right now, there are not.
The reason this is true right now is that there is one copy of the standard library for every program. So it needs to support all editions, because code from multiple editions may call standard library functions.
If we had multiple copies of the standard library, you may end up with issues where two different programs can't interoperate because they'd be using different versions of the same crate, and given that one of the most important features of the standard library is interoperation, this is a huge drawback for the stdlib specifically.
(There may be other technical issues, I am not an expert here, but that's the biggest hurdle as far as I know.)
You’re welcome. (I imagine that you’d get the same version conflict situation with your idea btw: std::2018::Option is not the same type as std::2021::Option.)
Sure but you don't have to use them, is the point I'm trying to make. They don't affect modern code and while it's annoying they are used in older code there is at least a path forward to "upgrade" the code to the modern equivalents.
There has been talk on the internals forum of "gating" deprecated parts of the std on a new edition. So the deprecated feature will be hidden for crates that declare `edition = '2030'` but will be available for crates using an older edition. Essentially turning the warning into an error.
But this is just talk at the moment. Currently there is no mechanism to implement this. It would also be a challenge for documentation.
Yes; this is so far off, and is not even at the RFC stage, that I didn't mention it. But you're right that maybe, someday, we could make it even harder for folks to call these things in newer editions.