4 ms·

> 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!(

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

Izkata 7y ago
> But that means my code is stuck on Rust 2015. ...can't you upgrade and choose not to make that change? Did something happen to make that not compile? (not a Rust user)
- boardwaalk 7y ago
  It looks like they might need to use "r#try!(...)" in Rust 2018 (a trivial search replace, 'cargo fix' might do it too, not sure), but the macro is still available: https://doc.rust-lang.org/stable/std/macro.try.html 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).
  - davidcuddeback 7y ago
    Thanks. Didn't know about the raw identifier syntax. That's kinda ugly, so I'd probably still go with copying it to all of my projects and giving it a new name if I were to update to Rust 2018.
    - alvarelle 7y ago
      On the other hand, you could argue that the r# gives you "more prominence" which is exactly the stated goal of using that macro.
- davidcuddeback 7y ago
  > Did something happen to make that not compile? `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.
  - gpm 7y ago
    Just to expand on the editions things, editions are local to the crate. A Rust 2015 crate can freely use a Rust 2018 crate and the reverse. So davidcuddeback isn't being locked out of using up to date dependencies either.
  - majewsky 7y ago
    > I can't think of a good name for a replacement macro What about do_or_do_not!(). After all, there is no try!(). ;)
    - davidcuddeback 7y ago
      Heh. That's the argument that was made against using Rails' `try()` method at my last place of work. Made me laugh. Thanks. :)
deleted 7y ago
[deleted]
swalladge 7y ago
> If something I need is added to Rust 2018 or a later edition, I'll be forced to update or backport. Should add that new editions with breaking changes are only expected to happen rarely (iirc every 3 years), a large difference to 6 weeks.
fluffything 7y ago
> If something I need is added to Rust 2018 or a later edition 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.

Izkata 7y ago

> But that means my code is stuck on Rust 2015. ...can't you upgrade and choose not to make that change? Did something happen to make that not compile? (not a Rust user)

boardwaalk 7y ago
It looks like they might need to use "r#try!(...)" in Rust 2018 (a trivial search replace, 'cargo fix' might do it too, not sure), but the macro is still available: https://doc.rust-lang.org/stable/std/macro.try.html 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).
- davidcuddeback 7y ago
  Thanks. Didn't know about the raw identifier syntax. That's kinda ugly, so I'd probably still go with copying it to all of my projects and giving it a new name if I were to update to Rust 2018.
  - alvarelle 7y ago
    On the other hand, you could argue that the r# gives you "more prominence" which is exactly the stated goal of using that macro.
davidcuddeback 7y ago
> Did something happen to make that not compile? `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.
- gpm 7y ago
  Just to expand on the editions things, editions are local to the crate. A Rust 2015 crate can freely use a Rust 2018 crate and the reverse. So davidcuddeback isn't being locked out of using up to date dependencies either.
- majewsky 7y ago
  > I can't think of a good name for a replacement macro What about do_or_do_not!(). After all, there is no try!(). ;)
  - davidcuddeback 7y ago
    Heh. That's the argument that was made against using Rails' `try()` method at my last place of work. Made me laugh. Thanks. :)

deleted 7y ago

[deleted]

swalladge 7y ago

> If something I need is added to Rust 2018 or a later edition, I'll be forced to update or backport. Should add that new editions with breaking changes are only expected to happen rarely (iirc every 3 years), a large difference to 6 weeks.

fluffything 7y ago

> If something I need is added to Rust 2018 or a later edition 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.