Idea: Add option methods for return Result<Option<U>, T>

[Nokel81]

It is sometimes very useful to have methods on options that can return a result which can then subsequently be tried away using ?.

So I propose adding resulting_... methods such as resulting_and_then which acts like and_then currently but has the following signature

pub fn resulting_and_then<U, E, F>(self, f: F) -> Result<Option<U>, E> where
    F: FnOnce(T) -> Result<Option<U>, E>

[vorner]

Apart from the naming (following stuff in eg. itertools or rayon, I’d expect something like this to be try_and_then), I guess if we go this way, the number of such methods will explode a lot (someone else will want Option<Result<U, E>>, etc…).

When dealing with such things, I often find myself wishing transpose was stabilized. But it might help a lot.

[Nokel81]

I can definitely see how that function is useful and it could be a substitute but I think that it would also be much more verbose then this needs to be.

I agree on try_... being a better name though.

[runiq]

When dealing with such things, I often find myself wishing transpose was stabilized. But it might help a lot.

This is going to be stabilized in 1.33.

[Nokel81]

Good to know. Still think that it would make it very verbose to use that constantly. Namely:

val.and_then(|v| f.might_return_result()).transpose()?.and_then(...)...;