Option::try_get_or_insert_with

[lolbinarycat]

Proposal

Problem statement

It is often desirable to call Option::get_or_insert_with with a fallible closure.

Motivating examples or use cases

Simple memoization/caching of fallible operations where failure of the option would be fatal, and thus reserving space to cache the whole Result would be a waste.

An example would be an expensive directory traversal of a dir that is expected to maintain integrity.

This is useful for a lazy query pattern similar to that used in rustc.

Solution sketch

impl<T> Option<T> {
  pub fn get_or_insert_with<F, E>(&mut self, f: F) -> Result<&mut T, E> where F: FnOnce() -> Result<T, E>;

Alternatives

• Use unwinding
• Some other sort of nonlocal control flow for closures.
• Putting this in some sort of extension trait crate analogous to itertools

Links and related work

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[kennytm]

pub fn get_or_insert_with<F, E>(&mut self, f: F) -> Result<&mut T, E> where F: FnOnce() -> Result<T, E>;

I think it should be generalized to return any R: Try than allowing only Result 🤔

use std::ops::{Residual, Try};

pub fn try_get_or_insert_with<'a, R, F>(
    &'a mut self,
    f: F,
) -> <R::Residual as Residual<&'a mut T>>::TryType
where
    F: FnOnce() -> R,
    R: Try<Output = T, Residual: Residual<&'a mut T>>,
{
    if let None = self {
        *self = Some(f()?);
    }
    Try::from_output(unsafe { self.as_mut().unwrap_unchecked() })
}

[lolbinarycat]

@kennytm doesn't that block this function on Try being stabilized? Stuff like MutexGuard::try_map is implemented with Result.

besides, the type signature for that with Option as the residual seems quite confusing.

[kennytm]

doesn't that block this function on Try being stabilized?

No, Iterator::try_fold and try_for_each are stable.

Stuff like MutexGuard::try_map is implemented with Result.

array::try_map, Iterator::{try_collect, try_find, try_reduce} all use residuals.

---

also 🚲🏠 maybe the function should be named get_or_try_insert_with instead of try_get_or_insert_with.

[Amanieu]

We discussed this in the @rust-lang/libs-api meeting and are happy to accept version using the Try trait described by @kennytm.

Please open a tracking issue and open a PR to rust-lang/rust to add it as an unstable feature. You can close this ACP once the tracking issue has been created.

[lolbinarycat]

Opening a tracking issue, using the name Option::get_or_try_insert_with for consistency with get_or_try_init.

[Amanieu]

I would prefer if the name was consistent with the existing get_or_insert_with method. Either try_get_or_insert_with or get_or_try_insert_with.

[lolbinarycat]

@Amanieu get_or_try_insert_with is what i chose... what's the issue?

[Amanieu]

Sorry I misread your message.