Rust

7228 readers

126 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 1 day ago by nemeski@mander.xyz to c/rust@programming.dev

11 comments fedilink hide all child comments

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

[–] BB_C@programming.dev 2 points 1 day ago (1 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 9 points 1 day ago (1 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 1 day ago (4 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 1 points 2 hours ago

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

[–] TehPers@beehaw.org 7 points 1 day ago

A lot of code doesn't really care where the error came from. This can be useful when using anyhow in application code, for example.

For library code, I don't see myself really using it, so it'll live next to all the other functions I don't use there I guess.

[–] anton@lemmy.blahaj.zone 3 points 1 day ago (1 children)

You can already :
res_res??;

I think it's more for cases where you don't want to return, like

let new_res = old_res.map(func).flatten();

[–] sukhmel@programming.dev 4 points 1 day ago

This, it's not a thing that happens often, but there were a couple of times when flatten would've been handy

This was also usually a result of a chain of and_then that could do with some flattening. This could've been rewritten as a separate function to make use of ?, but it seems to be a bigger trouble than use

[–] Ephera@lemmy.ml 3 points 1 day ago

Yeah, I can see your point. It's certainly not something you should overuse, just because it's convenient.

I feel like the redeeming points are that it will only be available, if it's the same error type. And if you use a catch-all error type, like anyhow::Error, which makes it likely for nested results to use the same error type, then it's likely that you can use ?? already.
So, personally, I feel like it isn't something that juniors will readily/wrongfully incorporate into their error handling routine and rather it is a tool that's available for when you know what you're doing.