4 ms·

I have one better: the try block pattern. https://doc.rust-lang.org/beta/unstable-book/language-features/try-blocks.html https://doc.rust-lang.org/beta/unstabl

I have one better: the try block pattern. https://doc.rust-lang.org/beta/unstable-book/language-features/try-blocks.html https://doc.rust-lang.org/beta/unstable-book/language-featur...

oniony 10mo ago
Now that is pretty cool.
Sytten 10mo ago
I want that stabilized so bad but it's not been really moving forward.
- mmastrac 10mo ago
  I was not a fan when I first saw it but I'm becoming desperate to have it the more Rust I write.
- koakuma-chan 10mo ago
  #![feature(try_blocks)] You only live once.
  - dwattttt 10mo ago
    I've tried it recently, from memory error inference wasn't that great through it.
    - JoshTriplett 10mo ago
      That's exactly what's currently being fixed before stabilizing it.
- mbrubeck 10mo ago
  There's some active work recently on fixing blocking issues, e.g.: https://github.com/rust-lang/rust/pull/148725 https://github.com/rust-lang/rust/pull/148725 https://github.com/rust-lang/rust/pull/149489 https://github.com/rust-lang/rust/pull/149489
- stouset 10mo ago
  Out of curiosity why can’t a block just do this natively?
  - lunar_mycroft 10mo ago
    Because then you couldn't use ? to propagate errors if they occurred inside any loops or branches within the function, which would be a significant limitation.
  - masklinn 10mo ago
    Because it would massively alter langage semantics? It converts returns from the nearest function into returns from the nearest (try) block.
tayo42 10mo ago
Why does this need special syntax? Couldn't blocks do this if the expression returns a result in the end?
- koakuma-chan 10mo ago
  One reason is that would be a breaking change.
- bobbylarrybobby 10mo ago
  Try blocks let you encapsulate the early-return behavior of Try-returning operations so that they don't leak through to the surrounding function. This lets you use the ? operator 1. when the Try type doesn't match that of the function this is taking place in 2. when you want to use ? to short circuit, but don't want to return from the enclosing function. For instance, in a function returning Result<T,E>, you could have a try block where you do a bunch of operations with Option and make use of the ? operator, or have ? produce an Err without returning from the enclosing function. Without try blocks, you pretty much need to define a one-off closure or function so that you can isolate the use of ? within its body.
- mwcz 10mo ago
  The best part of try blocks is the ability to use the ? operator within them. Any block can return a result, but only function blocks (and try blocks) can propagate an Err with the ? operator.
- jeroenhd 10mo ago
  Not without being able to use the ? operator. The closest thing I can think of that will let you return a result from within a separate scope using a set of foo()? calls would be a lambda function that's called immediately, but that has its own problems when it comes to moving and it probably doesn't compile to very fast code either. Something like https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=52069d6bcfae04843412cb84346cb827 https://play.rust-lang.org/?version=stable&mode=debug&editio...
valcron1000 10mo ago
One of the first things I tried in Rust a couple of years ago coming from Haskell. Unfortunately it's still not stabilized :(
loeg 10mo ago
Can this just be done as a lambda that is immediately evaluated? It's just much more verbose. let x = (|| -> Result<i32, std::num::ParseIntError> { Ok("1".parse::<i32>()? + "2".parse::<i32>()? + "3".parse::<i32>()?) })();
- saghm 10mo ago
  My instinct is this would get hairy much faster if you want to actually close over variables compared to using a block.
  - loeg 10mo ago
    If the verbose return type syntax can't be elided, I think it's more or less dead as a pattern.
  - ahartmetz 10mo ago
    Not sure if that is relevant to your point, but: For better and for worse, closing over any outer scope variables is syntactically free in Rust lambdas. You just access them.
    - nicoburns 10mo ago
      It's syntactically free, but it can cause borrow-checker errors thst cause your code to outright fail to compile.
      - saghm 10mo ago
        Yes, exactly. My concerns were semantic, not syntactic.
- rendaw 10mo ago
  That prevents other control flow mechanisms (return, break) from operating past the function boundary. In general, I avoid single-callsite functions as much as possible (including the iterator api) for this reason.
satvikpendem 10mo ago
Ah yes, do-notation.

I have one better: the try block pattern. https://doc.rust-lang.org/beta/unstable-book/language-features/try-blocks.html https://doc.rust-lang.org/beta/unstable-book/language-featur...

oniony 10mo ago

Now that is pretty cool.

Sytten 10mo ago

I want that stabilized so bad but it's not been really moving forward.

mmastrac 10mo ago
I was not a fan when I first saw it but I'm becoming desperate to have it the more Rust I write.
koakuma-chan 10mo ago
#![feature(try_blocks)] You only live once.
- dwattttt 10mo ago
  I've tried it recently, from memory error inference wasn't that great through it.
  - JoshTriplett 10mo ago
    That's exactly what's currently being fixed before stabilizing it.
mbrubeck 10mo ago
There's some active work recently on fixing blocking issues, e.g.: https://github.com/rust-lang/rust/pull/148725 https://github.com/rust-lang/rust/pull/148725 https://github.com/rust-lang/rust/pull/149489 https://github.com/rust-lang/rust/pull/149489
stouset 10mo ago
Out of curiosity why can’t a block just do this natively?
- lunar_mycroft 10mo ago
  Because then you couldn't use ? to propagate errors if they occurred inside any loops or branches within the function, which would be a significant limitation.
- masklinn 10mo ago
  Because it would massively alter langage semantics? It converts returns from the nearest function into returns from the nearest (try) block.

tayo42 10mo ago

Why does this need special syntax? Couldn't blocks do this if the expression returns a result in the end?

koakuma-chan 10mo ago
One reason is that would be a breaking change.
bobbylarrybobby 10mo ago
Try blocks let you encapsulate the early-return behavior of Try-returning operations so that they don't leak through to the surrounding function. This lets you use the ? operator 1. when the Try type doesn't match that of the function this is taking place in 2. when you want to use ? to short circuit, but don't want to return from the enclosing function. For instance, in a function returning Result<T,E>, you could have a try block where you do a bunch of operations with Option and make use of the ? operator, or have ? produce an Err without returning from the enclosing function. Without try blocks, you pretty much need to define a one-off closure or function so that you can isolate the use of ? within its body.
mwcz 10mo ago
The best part of try blocks is the ability to use the ? operator within them. Any block can return a result, but only function blocks (and try blocks) can propagate an Err with the ? operator.
jeroenhd 10mo ago
Not without being able to use the ? operator. The closest thing I can think of that will let you return a result from within a separate scope using a set of foo()? calls would be a lambda function that's called immediately, but that has its own problems when it comes to moving and it probably doesn't compile to very fast code either. Something like https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=52069d6bcfae04843412cb84346cb827 https://play.rust-lang.org/?version=stable&mode=debug&editio...

valcron1000 10mo ago

One of the first things I tried in Rust a couple of years ago coming from Haskell. Unfortunately it's still not stabilized :(

loeg 10mo ago

Can this just be done as a lambda that is immediately evaluated? It's just much more verbose. let x = (|| -> Result<i32, std::num::ParseIntError> { Ok("1".parse::<i32>()? + "2".parse::<i32>()? + "3".parse::<i32>()?) })();

saghm 10mo ago
My instinct is this would get hairy much faster if you want to actually close over variables compared to using a block.
- loeg 10mo ago
  If the verbose return type syntax can't be elided, I think it's more or less dead as a pattern.
- ahartmetz 10mo ago
  Not sure if that is relevant to your point, but: For better and for worse, closing over any outer scope variables is syntactically free in Rust lambdas. You just access them.
  - nicoburns 10mo ago
    It's syntactically free, but it can cause borrow-checker errors thst cause your code to outright fail to compile.
    - saghm 10mo ago
      Yes, exactly. My concerns were semantic, not syntactic.
rendaw 10mo ago
That prevents other control flow mechanisms (return, break) from operating past the function boundary. In general, I avoid single-callsite functions as much as possible (including the iterator api) for this reason.

satvikpendem 10mo ago

Ah yes, do-notation.