Result::flatten()is probably my favorite addition, but those lifetime linter changes might be really good, too.I’m more excited about
File::lockand friends. I don’t currently have a use-case, but surely it’ll help w/ something like a SQLite implementation in Rust.Result::flatten()is probably my favorite additionIt’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!
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).
(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.A lot of code doesn’t really care where the error came from. This can be useful when using
anyhowin 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.
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();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_thenthat 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
