ACP: Add Option::reduce

[orlp]

Proposal

Problem statement

I regularly run into the situation where I have two Options, and I'd like to combine them in some way. This almost always takes the the following form:

match (l, r) {
    (Some(l), Some(r)) => Some(f(l, r)),
    (Some(l), None) => Some(l),
    (None, Some(r)) => Some(r),
    (None, None) => None,
}

This is rather verbose for ultimately something very simple.

Motivating examples or use cases

Searching for (Some(l), Some(r)) => on Github already gives dozens and dozens of matches for this pattern, even when looking for specific variable names (l and r). Not all results (or even most) of this query match this pattern, but there is still a lot of matches for it.

Solution sketch

I think we should add the following function to Option<T>:

impl<T> Option<T> {
    pub fn reduce<F: FnOnce(T, T) -> T>(self, other: Option<T>, f: F) -> Option<T> {
        match (self, other) {
            (Some(l), Some(r)) => Some(f(l, r)),
            (Some(l), None) => Some(l),
            (None, Some(r)) => Some(r),
            (None, None) => None,
        }
    }
}

I'm open to other names than reduce, it just seemed follow Iterator::reduce closely.

Alternatives

There is the following alternative,

l.into_iter().chain(r).reduce(f)

but this is quite a bit longer and less readable/clean in my opinion (and also requires a FnMut). There is also the micro-crate opt_reduce which adds precisely this method in an extension trait.

Unlike a lot of other methods on Options, it is not possible to neatly express this method using ? short-circuiting. The status quo essentially always boils down to the above verbose match statement. If you know your pattern jutsu well you can avoid one extra match arm (but I'm not sure if it's actually more readable):

match (l, r) {
    (Some(l), Some(r)) => Some(f(l, r)),
    (Some(x), None) | (None, Some(x)) => Some(x),
    (None, None) => None,
}

Links and related work

This has been discussed and closed before:

• #84695 (2021)
• #87036 (2021)

Nevertheless, I still run into this pattern a lot and I think Option::reduce is quite a natural addition to the standard library, so I'm bringing it up again.

[abgros]

The code in your problem statement can be shortened to

match (l, r) {
	(Some(l), Some(r)) => Some(f(l, r)),
	(l, r) => l.or(r),
}

[WaffleLapkin]

Another alternative if you know pattern jutsu is

match (self, other) {
    (Some(l), Some(r)) => Some(f(l, r)),
    (res @ Some(_), None) | (None, res) => res,
}

But I think the method would be a lot cleaner than any of the matches presented in this thread.

[cuviper]

You can flip that to be even simpler:

match (self, other) {
    (Some(l), Some(r)) => Some(f(l, r)),
    (None, res) | (res, None) => res,
}

edit: actually the flip doesn't matter, you just need to match that any explicit None returns the other.

[traviscross]

We talked about this in the libs-api call today and decided to accept this ACP in a more generic form:

impl<T> Option<T> {
    fn reduce<U, R, F>(self, other: Option<U>, f: F) -> Option<R>
    where
        T: Into<R>,
        U: Into<R>,
        F: FnOnce(T, U) -> R,
    {
        match (self, other) {
            (Some(a), Some(b)) => Some(f(a, b)),
            (Some(a), _) => Some(a.into()),
            (_, Some(b)) => Some(b.into()),
            _ => None,
        }
    }
}

(This was proposed by @programmerjake in #328 (comment).)

During the call, our analysis was that this would not cause undue inference problems (due to the FnOnce(T, U) -> R providing a constraint), but this is something we'll of course want to keep an eye out for while this is in nightly.

On the name, we considered other options, including merge and fold, but in the end decided that reduce is the best choice. The signature and behavior of this function is closest in spirit to reduce on Iterator, and when we mirrored zip between Iterator and Option, we kept the name the same, so it's worth doing that here too.

It's for similar reasons that we decided to accept this even though we'd previously rejected it in #328. We have zip on Option, and this reduce function is a kind of sibling to that. Where zip is a kind of "and", reduce is a kind of "or". It makes sense to have both.

[WaffleLapkin]

During the call, our analysis was that this would not cause undue inference problems (due to the FnOnce(T, U) -> R providing a constraint), but this is something we'll of course want to keep an eye out for while this is in nightly.

I'm not sure this always works. The function can be generic or a closure, in which case it won't necessarily help inference.