Planning the Rust 2021 Edition
blog.rust-lang.org
blog.rust-lang.org
The module system was a big change, and the macro changes caused quite a bit of breakage. Both were important.
The changes here are nice to have, especially the partial struct borrowing. The prelude additions are convenient, but not terribly relevant anymore for me since rust-analyzer gained support for automatic trait imports. The new resolver is really helpful, but can also be changed in Cargo.toml. The new edition will just have the new resolver as the default.
This amount of changes would not lead to a breaking release in other languages. Which is a good thing!
Rust has been excellent about maintaining backwards compatability. The 2015 edition still works just fine on new compilers. Questionable changes are regularly tested against all crates on crates.io to prevent regressions. Developers also proactively submit fixes to crates for tiny breaking compiler/std fixes before they land.
The evolution of Rust has been very significant and impactful, while still remaining responsible and executed with a lot of competence, supported by good tooling.
I assume this edition is almost as much about maintaining institutional knowledge on how to do an edition as it is about the actual breaking features. It's quite easy to forget a lot of things over 6 years, so doing it regularly is important.
But still, the list of breaking changes here is quite small, and mostly some edge cases that will not impact the overwhelming majority of code.
Glad to see the language maturing.
Evolving infrastructure around the language is much more important than evolving the language at this point.
I'm not saying that C++2020 would be a bad change (it's not as it is modernizing the language), but the amount of things a C++ developer has to learn is tiring as the language improves.
I suspect it's simply a limitation of features to let the compiler version improve but have an explicit list of supported/unsupported feature every 4 years to avoid the fragmentation.
But I can't find information about this on the article.
The closest equivalent to editions in other languages are specification revisions. For example, with the C language, you have the C99 standard from 1999, the C11 standard from 2011, and so on. Each compiler will have a default setting for which standard to follow, but you can usually change it via command-line flag for each invocation (e.g. `-std=c99` in GCC). So you can have a file written in C99 next to a file written in C11.
Introducing a new edition enables some changes to the language that are otherwise not possible with Rust's strict backwards-compatibility rules. For example, Rust 2018 introduced the "async" and "await" keywords. In Rust 2015, you could have a variable called "async". That's not possible in Rust 2018 anymore, so that's a breaking change. But each crate specifies what edition it's using in its Cargo.toml, so you can mix an older crate written in Rust 2015 that uses that variable name somewhere in its code, with a newer crate written in Rust 2018 (or, soon, Rust 2021).
So the Rust team doesn't have to do a single release where they say "all code using async as a variable name is broken now", they can continue supporting old code while also enabling new code at the same time.