My understanding is that, since the edition is a per-crate property, crates that don't jump to 2018 aren't any worse off, and will continue to compile on both old and new compilers. I'd also be interested to know whether `cargo fix` covers the module changes for you.

(EDIT: I now realize you're talking about crates that will continue development on Rust 2015 specifically because they want to target older compilers, which is a different concern from what I was addressing. But now I'm not sure what the concern actually is. Even if you stay on Rust 2015, what reason is there to not upgrade your compiler? Both editions remain supported in 1.31 and will be for...ever, as far as I know.)

`cargo fix` probably covers it, but `cargo new` defaults to Rust 2018, which was kind of annoying when I was getting errors on code from another project that worked fine there.

There isn't a reason not to upgrade the compiler. My concern is that if I stay with Rust 2015 nothing changes for me, but if I need to fix a bug in someone's library there is a good chance they'll be on Rust 2018 (or vice versa). My concern is with the mental aspect of needing to remember the differences, not the technical differences.

It's possible that there isn't much to remember. Admittedly, I haven't yet looked at what the module changes are; but it still bothers me that such basic code no longer works.

That's a great point! Helping devs get up to speed on the changes is definitely a significant concern for editions, which is, I'm sure, why they put so much effort into creating a dedicated edition guide: https://doc.rust-lang.org/edition-guide/

Sure, the rust team is really good about documentation. I think that I worded things poorly though. One of the reasons that I started using rust is that the rust team said that once they hit 1.0 they would not make breaking changes (unless there was a soundness bug). While Rust 2018 technically keeps this promise since Rust 2015 will continue to compile and interoperate, I do not feel that it keeps the spirit of this promise; which is frustrating to me.

Backwards-compatibly changing existing features feels qualitatively the same to me as adding new features. In either case you can ignore them until you need to work on a codebase that uses them.

There doesn't tend to be that much support for older compilers in the Rust community (upgrading is so easy...). So I'd expect pretty much every crate to upgrade over the next year or so.

I agree that most crates will upgrade, but there are some very prominent crates which maintain compatibility with old rust versions. An example is the regex crate which works on rust 1.20+.

To be clear, rust 2015 code compiles just fine on new compilers, and will indefinitely. That’s a key part of it! Nothing should change with regards to these crates; they already weren’t using new features anyway, in order to maintain that compatibility.

Sure, I understand that. But if I've only ever used Rust 2018 and I go to submit a PR to the regex crate, I now need to be aware of any differences between the two versions.

It might not be a big deal, but a few weeks ago I started a new project that was going to reuse code from an existing project. The new project defaulted to 2018 (nightly compiler) and I got a bunch of errors with my module imports. It was just frustrating because it felt like it was a breaking change and one of the reasons I started using Rust is the promise of no breaking changes.

Is this not the situation when any new feature is added to a language?

That’s fair!

These kinds of changes are generally on par with other “never break” languages like Java and C++. Java 1.4 feels very different than Java 10.

It’s tough!

If you want to use Rust 2015, just do so?

I fail to see how Rust editions could be much smoother managed. Or should they never fix anything in the language?

For what it's worth you can write 2018-style modules code in 2015 crates (perhaps modulo a few edge cases?). So if you're willing to switch to that you can have one style across both editions.

You can use a 2018 crate from a 2015 crate (and vice versa) but you can’t “expose rust 2015” or something. There’s raw identifiers for anything that would be incompatible. That would require a new rustc, of course.

I'm... not sure you replied to the right comment here? What I'm talking about is writing 2018-style paths (starting with `crate::`, etc) in a 2015-edition crate, so you don't have to switch between two path styles when you switch between crates.

Ah. I just misunderstood what you meant. Sorry!