> I need to now change my code in order to keep it idiomatic
I'm not a Rust person so maybe I'm missing something, but why does the OP need to keep the code idiomatic? Can't the changing fashions in what's idiomatic be ignored?
I'm not a Rust person so maybe I'm missing something, but why does the OP need to keep the code idiomatic? Can't the changing fashions in what's idiomatic be ignored?
They absolutely can, but you might be stuck on an older "edition" of Rust. I've stuck with `try!()` for error-handling, because I think error-handling deserves more prominence than a single character. But that means my code is stuck on Rust 2015. If something I need is added to Rust 2018 or a later edition, I'll be forced to update or backport.
...can't you upgrade and choose not to make that change? Did something happen to make that not compile?
(not a Rust user)
https://doc.rust-lang.org/stable/std/macro.try.html
It's trivial to implement yourself, too (if you, for example, wanted to give it a non-reserved name).
`try` became a reserved keyword in Rust 2018 and the `try!()` macro was dropped (edit: not dropped, see @boardwaalk's comment). I could copy the old macro to all of my code bases and give it a new name. The two things stopping me from doing that are (1) I don't have any reason to update to Rust 2018, and (2) I can't think of a good name for a replacement macro. I'm thinking `check!()`, but not sold on the name.
> (not a Rust user)
One thing to know about Rust 2015 vs 2018 vs future "editions" is that they're a distinct versioning mechanism from Rust 1.23, 1.24, etc. The latest version of the Rust compiler still supports Rust 2015 and I believe it's been promised to be supported in perpetuity. So it's not like I run a risk of being without a Rust 2015 compiler available.
What about do_or_do_not!(). After all, there is no try!(). ;)
Should add that new editions with breaking changes are only expected to happen rarely (iirc every 3 years), a large difference to 6 weeks.
Most new language getting added to Rust, are added to the Rust 2015 edition (e.g. NLL). If you need a language feature that is added to a later edition only (like the `try` keyword), that's because the feature is incompatible with code being used in earlier editions (which declared a macro with the keyword name).
You can continue using the macro by just using raw-literal syntax.. but my old Rust code tends to "just work", so I don't really need to update it. My crates are also very small, so if I'd ever need an update, it wouldn't take too long - but haven't had to do that yet, so can't comment.
I tend to write most of my new code on new crates, so I default them to whatever edition was the default when I create them, and never look back.
I have lot of 2015 crates in my dependency tree, and that works just fine.
You probably don’t want to live like that forever, but it’s a way of not being “required” to upgrade large code bases.
Speaking as somebody who has maintained several medium sized Rust code bases over the years, I can comfortably say that it's not a big deal.
What _has_ been a big deal, on the other hand, is getting excited about what I can do with extremely unstable libraries, and then spending a lot of time keeping up with their breaking changes. But I'd be a bit silly to complain about this; in each case, I opted in to an immature ecosystem very early on because I was excited about being part of its early growth. I don't expect to have my cake and eat it, too.