News for hackers. Stuff that matters.
Re:Rust: A Critical Retrospective by aaron_m04 on Thursday May 19, 2022 @11:35AM (#31436068)
I have noticed this tendency as well.

To counteract it, I write exit-early code like this:

    let foo_result = foo();
    if let Err(e) = foo_result {
        return Bar::Fail(e);
    }
    let foo_result = foo_result.unwrap();
    ...
Re:Rust: A Critical Retrospective by mathstuf on Thursday May 19, 2022 @11:51AM (#31436249)
Any reason why this wasn't preferred?

    let foo_result = foo()
        .map_err(Bar::Fail)?;
Re:Rust: A Critical Retrospective by veber-alex on Thursday May 19, 2022 @12:07PM (#31436486)
Bar::Fail is not wrapped in a Result type, so you can't use '?' with it (on stable at least).

You can write it like this:

  let foo_result = match foo() {
    Ok(v) => v,
    Err(e) => return Bar::Fail(e)
  };
Re:Rust: A Critical Retrospective by loeg on Thursday May 19, 2022 @12:23PM (#31436668)
The result type is the return from Foo -- Bar::Fail does not need to wrap Result. Foo is Result<T, E> and map_err() would convert it to Result<T, Bar::Fail>. I think GP's `map_err()?` is the most straightforward way of writing this idea (and it's generally speaking how I would suggest writing Rust code).
Re:Rust: A Critical Retrospective by veber-alex on Thursday May 19, 2022 @12:27PM (#31436724)
GP's code will return Result<_, Bar>, the original code we are trying to fix just returns Bar.
Re:Rust: A Critical Retrospective by loeg on Thursday May 19, 2022 @12:38PM (#31436867)
If you are writing code to handle Results, it’s going to be a lot less painful to just return Result.
Re:Rust: A Critical Retrospective by ntoskrnl on Thursday May 19, 2022 @11:41AM (#31436154)
I do this too, with a different spin on it:

  let foo = match foo() {
      Ok(foo) => foo,
      Err(err) => return Err(err),
  };
I was typing it out so often I made editor aliases `lmo` and `lmr` for Option and Result
Re:Rust: A Critical Retrospective by veber-alex on Thursday May 19, 2022 @11:47AM (#31436224)
let me introduce you to the famous '?' operator.

The code above can be written as:

  let foo = foo()?;
Re:Rust: A Critical Retrospective by ntoskrnl on Thursday May 19, 2022 @11:57AM (#31436325)
LOL you're right! I just pasted the template here, but my defaults are mostly equivalent to plain old `?`. I don't use the match if `?` would work.
Re:Rust: A Critical Retrospective by gardaani on Thursday May 19, 2022 @12:36PM (#31436856)
Early exit code would be easier to write if Rust supported guard let.
Re:Rust: A Critical Retrospective by veber-alex on Thursday May 19, 2022 @01:55PM (#31437937)
its coming soon, already available on nightly.

   let Some(x) = foo() else { return 42 };
Re:Rust: A Critical Retrospective by inferiorhuman on Thursday May 19, 2022 @10:21PM (#31442627)
I'd suggest that something like that is already achievable by having foo return an Option and combining it with unwrap_or.
Re:Rust: A Critical Retrospective by klodolph on Thursday May 19, 2022 @01:41PM (#31437738)
Like this?

    if let Ok(x) = my_func() {
        // ...
    }
Or do you mean something else?
Re:Rust: A Critical Retrospective by metaltyphoon on Thursday May 19, 2022 @01:41PM (#31437749)
Isn’t that a good general practice todo? Exit early
Re:Rust: A Critical Retrospective by icedchai on Thursday May 19, 2022 @08:02PM (#31441794)
You'd be surprised. For every person that things exit early is good, you'll run into another that prefers a single exit. At worked at a C++ shop that preferred "single exit", and some methods with an ungodly amount of conditions just to make this possible. Ugh.
Re:Rust: A Critical Retrospective by boolemancer on Friday May 20, 2022 @02:49AM (#31444139)
In my experience, a preference for single exit comes from C where you always need to make sure to clean up any resources, and an early exit is a great way to have to duplicate a bunch of cleanup logic or accidentally forget to clean things up.

Of course, that's what goto is actually good for.