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.
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.
Should add that new editions with breaking changes are only expected to happen rarely (iirc every 3 years), a large difference to 6 weeks.
...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!(). ;)