Add `unwrap_or_put` method to `Option<T>`

[leoyvens]

Originally suggested in #1278, an unwrap_or_put method on Option<T> would be useful, a common use case is lazy initialization. To illustrate the behaviour:

fn unwrap_or_put(&mut self, foo : T) -> T {
    if self.is_none() { self = Some(foo); }
    self.unwrap()
}

[withoutboats]

The code you've written would not compile beceause you need to take self rather than &mut self. But that is the signature and behavior of unwrap_or().

You would need to return a reference if you want to take a reference. If you want this behavior to mutate self as a side effect, there isn't a method that does this right now. I'm not sure you will find support for that, no option methods mutate the option in place right now.

If however, you just want a function that takes (&Option, T) -> &T, this brief composition will achieve that effect:

option.or(Some(foo)).as_ref().unwrap()

This will not change the state of the original option, though.

[leoyvens]

I see, perhaps the following would be a more feasible version of what I want:

fn or_put(&mut self, foo : T) -> &mut Option<T> {
    if self.is_none() { *self = Some(foo); }
    self
}

[ticki]

@leodasvacas Why not just use .map then?

[leoyvens]

Because I wish to mutate the original option without consuming it, which I believe that code achieves?

[ticki]

Actually, I'm wrong. I must have misunderstood what you want. You want a way to place a value if it's none.

[nagisa]

@leodasvacas I strongly suggest you to create a crate implementing functionality you seek and perhaps then petition for inclusion to the standard library.

To me it seems you only have a vague idea of what you want to achieve and implementing a crate will both make implementation available to you sooner and make clear how you want your idea to be implemented from an API standpoint.

[leoyvens]

@ticki Yes.
@nagisa You're right, I should think this through before thought vomiting here 😅

I'll reopen or make a new, better explained issue if I come to something that makes more sense.

[stuhood]

Can we reopen this one (and probably close #1416)? This seems like an important missing feature for field initialization.

As in the original example in the thread, it's particularly important when T is a reference, because the reference needs to point into the Option. unwrap_or_else isn't sufficient in that case.

[steveklabnik]

@stuhood small changes don't need to go through an RFC today; I would just send in a PR for this.

[stuhood]

Looks like this landed for rust-lang/rust#39288 as shahn/rust@8e02ad0 ... thanks @shahn!