[proto_lambda]

> It doesn’t seem that terrible to prohibit this (Probably some very good reason to counter this though!)

The simple reason is that the whole point of editions is that you absolutely do not have to worry about which one you choose. They are entirely localized to your crate, and code written in any edition can interact with code written in any other edition. With your suggestion, updating the edition used by a library crate would suddenly make it unusable for all code using an older edition.

[satvikpendem]

Then what's the point of editions, if the crates are forward and backward compatible?

[kevincox]

The point is that crates written against different editions are forwards and backwards compatible, but how the crate is written isn't.

So Rust can make a "breaking" change in a new edition. This isn't actually breaking because you need to "opt-in" by updating to the new edition. This allows many "breaking" changes without actually breaking the ecosystem. Each crate can upgrade whenever they feel like it (possibly never) and they can make this decision independently of any other crates.

For example look at the breaking changes introduced in the 2021 edition: https://doc.rust-lang.org/edition-guide/rust-2021/index.html. Each item on the left menu is a breaking change that was able to be shipped due to the edition system.

You are right that the edition system does create limits for what can be changed. However this is because doing so would have downsides. Notably if older editions couldn't depend on newer editions I may need to migrate my crate to a new edition in order to update a dependency to get a security fix. Edition updates are typically quite easy but it was still a conscious decision that they aren't ever required, unless you want to take advantage of the new features added in that edition.