3 ms·

> It's not any more verbose Seriously? I think this is way less readable: (|| -> Result<_,_> { bar(foo()?) })() than this: try { bar(foo()?)? } Also t

> It's not any more verbose Seriously? I think this is way less readable: (|| -> Result<_,_> { bar(foo()?) })() than this: try { bar(foo()?)? } Also try_blocks don't have to have a "catch". It's just five characters: "t" "r" "y" "{" "}". I don't see a need for "catch" either.

Arnavion 6y ago
The closure version would actually be (|| -> Result<_,_> { Ok(bar(foo()?)?) })() to be equivalent, since bar's Err type might need a From::from conversion via `?`. So the try-blocks version is even better in comparison. That said, if you include the `-> Result<_,_>` annotation in the closure case, you also need to include the `: Result<_,_>` annotation for the binding that the try-expr is being assigned to, otherwise the compiler won't know which impl of `std::ops::Try` to use. Of course, you can also use an annotation on the binding in the closure case and get rid of the annotation entirely. That is, the comparison is of: let r: Result<_, _> = (|| Ok(bar(foo()?)?))(); vs let r: Result<_, _> = try { bar(foo()?)? };
- octoberfranklin 6y ago
  I still find the second case far more readable. When you see "try{}" it says "this is here because I want to turn on ?-handling within this block". When you see a closure formed and then immediately applied it says... well I dunno. Frankly it seems to say "this expression should be simplifiable". In fact it's a huge wart on Rust that beta-reduction doesn't preserve well-formedness of expressions. Also if there were more stuff in the expression body it might not even be obvious at a glance that the closure is being formed-and-then-immediately-invoked, leading a reviewer to wonder "wtf is a closure doing here?".
  - Arnavion 6y ago
    Oh yes, my point was not that the try-blocks version was less readable. I agree that it's better and used to use it back when it was still called `do catch { }` and didn't do automatic-Ok-wrapping. I was just making the comparison fairer.

Arnavion 6y ago

The closure version would actually be (|| -> Result<_,_> { Ok(bar(foo()?)?) })() to be equivalent, since bar's Err type might need a From::from conversion via `?`. So the try-blocks version is even better in comparison. That said, if you include the `-> Result<_,_>` annotation in the closure case, you also need to include the `: Result<_,_>` annotation for the binding that the try-expr is being assigned to, otherwise the compiler won't know which impl of `std::ops::Try` to use. Of course, you can also use an annotation on the binding in the closure case and get rid of the annotation entirely. That is, the comparison is of: let r: Result<_, _> = (|| Ok(bar(foo()?)?))(); vs let r: Result<_, _> = try { bar(foo()?)? };

octoberfranklin 6y ago
I still find the second case far more readable. When you see "try{}" it says "this is here because I want to turn on ?-handling within this block". When you see a closure formed and then immediately applied it says... well I dunno. Frankly it seems to say "this expression should be simplifiable". In fact it's a huge wart on Rust that beta-reduction doesn't preserve well-formedness of expressions. Also if there were more stuff in the expression body it might not even be obvious at a glance that the closure is being formed-and-then-immediately-invoked, leading a reviewer to wonder "wtf is a closure doing here?".
- Arnavion 6y ago
  Oh yes, my point was not that the try-blocks version was less readable. I agree that it's better and used to use it back when it was still called `do catch { }` and didn't do automatic-Ok-wrapping. I was just making the comparison fairer.