Add transpose conversions for nested Option and Result#47193
Add transpose conversions for nested Option and Result#47193bors merged 1 commit intorust-lang:masterfrom
Conversation
|
r? @TimNN (rust_highfive has picked a reviewer for you, use r? to override) |
|
The general idea came up in the users forum too, including a few ways to generically convert |
|
review ping for you @TimNN! Pinging you on IRC too! |
|
The implementation looks good to me (although the last test is a bit hard to follow). cc @rust-lang/libs regarding if we want these impls or not. (Does this need a crater run?) |
|
The @rust-lang/libs team discussed this during triage today and our conclusion was that we may not wish for these methods in precisely this form. We were having difficulty (but @cramertj feel free to fill in the gaps) coming up with situations where you'd use this via something like |
|
We were having difficulty coming up with situations where you would need these as // Nobody would write this.
fn f<T, E, R: Into<Result<Option<T>, E>>>(input: R) {If we don't need them to be generic this way then we don't need them to be trait impls, so inherent methods could be a more discoverable solution and also behave better where type inference around an into-conversion would be ambiguous. impl<T, E> Result<Option<T>, E> {
pub fn transpose(self) -> Option<Result<T, E>>;
}
impl<T, E> Option<Result<T, E>> {
pub fn transpose(self) -> Result<Option<T>, E>;
} |
|
Yeah I think that makes sense! |
|
People have certainly asked for the general functionality: I know there's one for |
f8aba68 to
2c0f47f
Compare
These impls are useful when working with combinator methods that expect an option or a result, but you have a Result<Option<T>, E> instead of an Option<Result<T, E>> or vice versa.
|
It sounds like the team is OK with the inherent methods, so I've updated the labels to reflect that. Please change it back if I read incorrectly. |
|
Review ping for you @TimNN! |
| assert_eq!(x, y.transpose()); | ||
| assert_eq!(x.transpose(), y); | ||
|
|
||
| let res: Result<Vec<i32>, BadNumErr> = |
There was a problem hiding this comment.
I find this part of the to be extremely hard to follow. Is there a specific purpose of this test? Is this a (simplified) real-world use case? Or is that supposed to test type inference?
There was a problem hiding this comment.
This is a simplified version of a real use-case I had. I arrived at this solution when trying to handle possible errors in a filter_map closure.
|
@bors r+ rollup |
|
📌 Commit c9ae249 has been approved by |
Add transpose conversions for nested Option and Result These impls are useful when working with combinator methods that expect an option or a result, but you have a `Result<Option<T>, E>` instead of an `Option<Result<T, E>>` or vice versa.
|
Just for the record, there was an earlier issue about a |
These impls are useful when working with combinator
methods that expect an option or a result, but you
have a
Result<Option<T>, E>instead of anOption<Result<T, E>>or vice versa.