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

libs
1

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>
2

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.

3 Likes
3

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.

4

This is going to be stabilized in 1.33.

3 Likes
5

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(...)...;
6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.