Follow up to “Changing the rules of Rust”(without.boats)
without.boats
Follow up to “Changing the rules of Rust”
https://without.boats/blog/follow-up-to-changing-the-rules-of-rust/
22 comments
> The first crate, foo, is in the 2024 edition, and defines a trait with a single generic method. The second crate, bar, is in the 2021 edition, depends on foo, and implements that trait for its own type.
I wasn’t aware that an early edition of rust can reference crates for a later edition. It doesn’t seem that terrible to prohibit this (Probably some very good reason to counter this though!). Editions give us the privilege of not having to constantly update crates that don’t really need to be changed whenever a new rust version comes out. If I do end up making changes to my crate and updating my dependencies then I don’t see it as such a pain to update the Rust Edition of my crate if said dependencies also happen to use a later edition.
I do, however, see one downside to this though and experienced it first hand in c# .net standard where it was way better to use the earliest version possible of .net standard for your library to maximise compatibility with things that use it. No incentive to use a later standard and therefore there was stagnation. May not be applicable because you normally distribute compiled binaries but food for thought.
I wasn’t aware that an early edition of rust can reference crates for a later edition. It doesn’t seem that terrible to prohibit this (Probably some very good reason to counter this though!). Editions give us the privilege of not having to constantly update crates that don’t really need to be changed whenever a new rust version comes out. If I do end up making changes to my crate and updating my dependencies then I don’t see it as such a pain to update the Rust Edition of my crate if said dependencies also happen to use a later edition.
I do, however, see one downside to this though and experienced it first hand in c# .net standard where it was way better to use the earliest version possible of .net standard for your library to maximise compatibility with things that use it. No incentive to use a later standard and therefore there was stagnation. May not be applicable because you normally distribute compiled binaries but food for thought.
> 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.
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.
Then what's the point of editions, if the crates are forward and backward compatible?
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.
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.
Sounds like what Python 2 to 3 should have been.
where do you think they learned it from? python 3 (like python's package management mess) is wonderful for PL because it was a very public materclass in decisions that seem reasonable, but work really badly in practice.
[deleted]
Follow-up from the author on Reddit:
> After a few more minutes thought:
> When you upgraded `foo` from 2021 to 2024, `cargo fix` would have had to add a `Leak` bound to the parameter on the method. Removing that bound would be a breaking change. Therefore, the issue could actually be in `bar`. But this also highlights another issue: it's a breaking change to start allowing `!Leak` types to be passed to any generic method of a trait, even with this firewall. That means like `Iterator::map` can't take a closure which has a `!Leak` type in its state, for example.
> But also what is the issue in `bar` if so? In 2021 edition, the interface of any trait you impl coming from a 2024 edition crate is tested under 2024 edition somehow? Does that work? What does the error message say to you?
> My point is not that this is impossible, but that its not easy at all.
https://www.reddit.com/r/rust/comments/16ltgn1/comment/k145i...
> After a few more minutes thought:
> When you upgraded `foo` from 2021 to 2024, `cargo fix` would have had to add a `Leak` bound to the parameter on the method. Removing that bound would be a breaking change. Therefore, the issue could actually be in `bar`. But this also highlights another issue: it's a breaking change to start allowing `!Leak` types to be passed to any generic method of a trait, even with this firewall. That means like `Iterator::map` can't take a closure which has a `!Leak` type in its state, for example.
> But also what is the issue in `bar` if so? In 2021 edition, the interface of any trait you impl coming from a 2024 edition crate is tested under 2024 edition somehow? Does that work? What does the error message say to you?
> My point is not that this is impossible, but that its not easy at all.
https://www.reddit.com/r/rust/comments/16ltgn1/comment/k145i...
[deleted]
tempodox(6)
dingi(3)
https://news.ycombinator.com/item?id=37545040