Hacker News Reader

Comment by hawski | Hacker News Reader

I find that Rust tends to have code that goes sideways more than downward. I prefer the latter and most C code bases, that I find elegant are like that.

It is like that, because of all the chaining that one can do. It is also just a feeling.

View on HN

There are two upcoming features, let chains and let else, to counter the sideways drift.

Sometimes it's also the formatter though that outputs intensely sideways drifting code: https://github.com/rust-lang/rust/blob/1.60.0/compiler/rustc...

I think it's because of the expression focus. Isn't it easier to make the code flow like a waterfall when it's imperative, but is harder to reason about values and state.

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();
    ...

Any reason why this wasn't preferred?

    let foo_result = foo()
        .map_err(Bar::Fail)?;

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)
  };

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

GP's code will return Result<_, Bar>, the original code we are trying to fix just returns Bar.

If you are writing code to handle Results, it’s going to be a lot less painful to just return Result.

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

let me introduce you to the famous '?' operator.

The code above can be written as:

  let foo = foo()?;

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.

Early exit code would be easier to write if Rust supported guard let.

its coming soon, already available on nightly.

   let Some(x) = foo() else { return 42 };

I'd suggest that something like that is already achievable by having foo return an Option and combining it with unwrap_or.

Like this?

    if let Ok(x) = my_func() {
        // ...
    }

Or do you mean something else?

Isn’t that a good general practice todo? Exit early

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.

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.

Reply on news.ycombinator.com