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)
};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.
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
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()?;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.
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.
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
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.
To counteract it, I write exit-early code like this: