Rust

7403 readers

74 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 2 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

EdTheLegendary@programming.dev

kahnclusions@programming.dev

torcherist@programming.dev

Announcing Rust 1.89.0 (blog.rust-lang.org)

submitted 2 months ago by nemeski@mander.xyz to c/rust@programming.dev

12 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] BB_C@programming.dev 3 points 2 months ago (8 children)

Result::flatten() is probably my favorite addition

It's rare to a have a negative reaction to a library addition. But I don't like this one at all actually.

For me, error contexts are as important as the errors themselves. And ergonomically helping with muddying these contexts is not a good thing!

[–] NGram@piefed.ca 10 points 2 months ago (7 children)

What scenarios do you envision a Result<Result<T, E>, E> having a different meaning than a Result<T, E>? To me, the messy Result type just seems like a case of something that should've been handled already (or properly propagated up).

[–] BB_C@programming.dev 1 points 2 months ago (6 children)

(stating the obvious)

You can already :

res_res??;
// or
res_res?.map_err(..)?;
// or
res_res.map_err(...)??;
// or
res_res.map_err(...)?.map_err(...)?;

With res_res.flatten()?, you don't know where you got the error anymore, unless the error type itself is "flatten-aware", which is a bigger adjustment than the simple ergonomic library addition, and can become itself a problematic pattern with its own disadvantages.

[–] sukhmel@programming.dev 2 points 2 months ago (1 children)

Wait, so you say res_res?? gives more information than res_res.flatten()?, do you?

I mean, this is a very trivial case and not best suited for flatten at all, but the information is lost in exactly the same way

[–] BB_C@programming.dev 1 points 2 months ago

Yes. Note that I'm replying to this:

messy Result type just seems like a case of something that should’ve been handled already (or properly propagated up).

My point was that without flattening, "provide context and propagate" vs. "directly propagate" is always explicit and precise, and is obviously already supported and easy to do.

Use with functional chaining, as pointed out by others, wasn't lost on me either. I've been using Option::flatten() for years already, because such considerations don't exist in that case.

load more comments (4 replies)