4 ms·
> 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,
by davidhyde 3y ago
> 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.
- proto_lambda 3y ago> 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 3y agoThen what's the point of editions, if the crates are forward and backward compatible?
- kevincox 3y agoThe 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 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.
- genter 3y agoSounds like what Python 2 to 3 should have been.
- adgjlsfhk1 3y agowhere 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.