3 ms·
`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 wo
by 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 agoThat'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 agoSure, 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 agoBackwards-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.