Add transpose conversions for nested Option and Result

[cramertj]

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.

[rust-highfive]

r? @TimNN

(rust_highfive has picked a reviewer for you, use r? to override)

[cuviper]

The general idea came up in the users forum too, including a few ways to generically convert Try types: https://users.rust-lang.org/t/convenience-method-for-flipping-option-result-to-result-option/13695

[carols10cents]

review ping for you @TimNN! Pinging you on IRC too!

[TimNN]

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?)

[alexcrichton]

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 .into(). We did think, however, that these could be useful as inherent methods on Option/Result types though, so maybe they'd be better there rather than via the From trait?

[dtolnay]

We were having difficulty coming up with situations where you would need these as Into conversions in a generic context.

// 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>;
}

[cramertj]

Yeah I think that makes sense! transpose or something seems good to me.

[shepmaster]

People have certainly asked for the general functionality:

• Is it possible to convert Option<Result<T, E>> to a Result<Option, E> without using match?

I know there's one for Result<Option<T>, E> somewhere, but not able to find it at the moment, so I'm in favor of some type of functionality.

[shepmaster]

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.

[kennytm]

Review ping for you @TimNN!

[TimNN]

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?

[cramertj]

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.

[TimNN]

@bors r+ rollup

[bors]

📌 Commit c9ae249 has been approved by TimNN

[golddranks]

Just for the record, there was an earlier issue about a try_map and flip methods: rust-lang/rfcs#1815 It lead to this crate that provides similar functionality than this conversion: https://crates.io/crates/try_map It's great to see that this is going to be in std, since this is a commonly needed functionality, but there's always a threshold to find & use external crates for trivial things.