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.

[–] anton@lemmy.blahaj.zone 5 points 2 months 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 5 points 2 months 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

load more comments (4 replies)