Tracking Issue for Result<Option> and Option<Result> Conversion

[cramertj]

Initial implementation in #47193.

[epage]

A nice-to-have but not required would be someway for us to make this general so it can be used with other types, for example with Either<Result>.

I saw Into mentioned in #47193 and the challenge is ergonomics.

[kennytm]

Does it make sense to implement transpose for Result<Result<T, E1>, E2>?

[qnighy]

Then perhaps Option<Option<T>>::transpose can also exist (maybe for consistency or for real use)? It's not an identity.

[Centril]

Nice addition 👍 The generalization of this, which we should experiment with when we get GATs, should just be sequenceA for any Traversable functor.

[clarfonthey]

Conversions for Option<Option<T>> and Result<Result<T, E1>, E2> are just catch { val? } andcatch { Ok(val??) }, so, I'm not sure if they need dedicated functions.

[qnighy]

Conversions for Option<Option<T>> and Result<Result<T, E1>, E2> are just catch { val? } and catch { Ok(val??) }

I don't think so. The code below doesn't compile.

#![feature(catch_expr)]

fn transpose<T, E1, E2>(x: Result<Result<T, E1>, E2>) -> Result<Result<T, E2>, E1> {
    do catch {
        Ok(x??)
    }
}

[clarfonthey]

@qnighy that's because you're missing From<E1> for E2

[qnighy]

@clarcharr perhaps are we talking about different functions? My understanding is that Result<Result<T, E1>, E2>::transpose is an involution. catch { Ok(val??) } isn't, as it transforms both Err(e) and Ok(Err(e)) into Err(e).

[goose121]

@clarcharr perhaps are we talking about different functions? My understanding is that Result<Result<T, E1>, E2>::transpose is an involution. catch { Ok(val??) } isn't, as it transforms both Err(e) and Ok(Err(e)) into Err(e).

Also, is it just me, or does catch { Ok(val??) } seem like a rather obscure expression? I feel like a Rust programmer coming across this who hasn't seen it before would be pretty confused.

[mexus]

Hi everyone,

is there anything which prevents this useful feature from being stabilized? I've come here from a link from the docs about the transpose_result feature, but I can't really find any ongoing argument here. Could it be that there's another issue with discussions towards stabilization of the feature?

Thanks :)

[cramertj]

Ping @rust-lang/libs this has been sitting around for a year now and I don't expect we'll see much more experimentation with it if folks have to rely on a nightly feature. What would y'all think about stabilizing?

[SimonSapin]

Sounds ok to me.

@rfcbot fcp merge

This issue tracks these methods:

impl<T, E> Option<Result<T, E>> {
    pub fn transpose(self) -> Result<Option<T>, E> {…}
}
impl<T, E> Result<Option<T>, E> {
   pub fn transpose(self) -> Option<Result<T, E>> {…}
}