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).
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.
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.
anton@lemmy.blahaj.zone
on 07 Aug 20:13
nextcollapse
You can already :
res_res??;
I think it’s more for cases where you don’t want to return, like
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
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.
sugar_in_your_tea@sh.itjust.works
on 08 Aug 14:13
collapse
I’m more excited about File::lock and friends. I don’t currently have a use-case, but surely it’ll help w/ something like a SQLite implementation in Rust.
threaded - newest
Result::flatten()is probably my favorite addition, but those lifetime linter changes might be really good, too.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!
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 :
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.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.
I think it’s more for cases where you don’t want to return, like
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 useA 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.
Wait, so you say
res_res??gives more information thanres_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
Yes. Note that I’m replying to this:
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.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.turso.tech ?