suggest ? over try!

[oli-obk]

The ? operator has hit stable. We should lint all uses of the try macro and suggest the new operator instead.

[llogiq]

Some people still prefer try!(_) for various reasons. Not sure a warning would be universally appreciated.

[oli-obk]

I know :( but even reading the rfc and tracking issue, the only complaint I could find is visibility, and even the complainers agree that it is just a syntax hilighting issue.

All in all, it is the recommended new way of doing error propagation, so I think we should suggest it.

Alternatively rustfmt could silently rewrite all code that doesn't have a macro_rules! try anywhere xD /s

[oli-obk]

cc @mbr opinions welcome :)

[mbr]

Some people still prefer try!(_) for various reasons. Not sure a warning would be universally appreciated.

I agree, but I feel that even these are split in two camps. Some people will want to keep writing try! while others (like me) will probably deem it not important enough to not go with the "standard", even though they might have preferred try!. A clippy warning would certainly reinforce the notion of ? being the "modern" try!.

This seems like a bikeshedding issue to me at this point. The worst outcome would be having both variants common and valid, preventing me to get thoroughly used to one way or another, so for this reason please pick one and stick to it!

Alternatively rustfmt could silently rewrite all code that doesn't have a macro_rules! try anywhere xD /s

I'm still recovering from impl TODO. Please don't =).

Though adding a flag to do this automatically might be a good idea.

[bluss]

The Rust book doesn't mention ? yet.

[bluss]

On the day after Rust 1.13 was released, I was all about teaching ? but it quickly ran into trouble with the book not mentioning it lol 😄 Made me rethink, It's going to be rolled out slowly at this pace.

[est31]

As someone who doesn't like ? in my codebases, I'd like an opposite check: warn every time ? is found, so that I don't have to check contributions for its usage.

[leshow]

@est31 The feature was merged into rust stable. I doubt rust's main linter is going to discourage it's use, that would be counterproductive.

[llogiq]

Despite it's recent stability, it's still a young feature (for example codegen doesn't always return the same bytecode as with try!IIIC), so its benefits have yet to be proven.

[Manishearth]

(for example codegen doesn't always return the same bytecode as with try!IIIC)

try! is now implemented as ?, so codegen should return the same bytecode.

edit: nope, my bad

[sinkuu]

try has not been ported to use ? operator yet. https://github.com/rust-lang/rust/blob/master/src/libcore/macros.rs#L309

[bluss]

try!() is Result specific; ? gives less type information, so rust-lang/rust/issues/36244 is an example of type inference related regression.

[bluss]

It doesn't serve Rust that people hesitate about adopting features(*) (when they are this kind of direct replacement). You could say I voted -1 on having ? but now when it is part of Rust, I'm all for working with it.

There is a codegen issue: rust-lang/rust#37939 (comment) . This missing simplification/optimizations also applies to the code Ok(try!(x)) itself (pointed out by eddyb), so regardless of old try or ? it benefits Rust to resolve it (not to mention other instances when these no-op match blocks appear).

(*) Edit: So yes, that means that Rust needs to do the work so that it's worth switching to ?.

[In-line]

It's still interesting to implement cargo lint for this : )

[ghost]

https://github.com/rust-lang/rfcs/blob/master/text/2388-try-expr.md#breakage-of-the-try-macro lists good points about ? vs try!.
Wouldn't it be the best/easiest to just mark try! deprecated?
It wouldn't break anything, no lint would be required and more people would switch to ?