5 ms·

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 o

by Twisol 8y ago

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.)

huntie 8y ago
`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.
- Twisol 8y ago
  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/ https://doc.rust-lang.org/edition-guide/
  - huntie 8y ago
    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.
    - tikue_ 8y ago
      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.

by Twisol 8y ago

huntie 8y ago

`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.

Twisol 8y ago
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/ https://doc.rust-lang.org/edition-guide/
- huntie 8y ago
  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.
  - tikue_ 8y ago
    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.