There's no clean way to move a value into an Option and get a reference to the value.

[canndrew]

I need to mutate an Option in place, setting it to Some(x), then get a reference to x. The only way to do this is:

*my_opt = Some(x);
let r = match *my_opt {
    Some(ref x) => x,
    None => unreachable!(),
}

I shouldn't need to pattern-match against my_opt if I already know that it's a Some. Having to use unreachable!() creates code-smell - it's often a red flag that code is wrong and if it isn't wrong it should ideally be possible to restructure it to get rid of the unreachable!().

This is actually a problem with enums generally but without a way to fix the more general problem I think it should at least be fixed for Option.

I propose that either one of the following methods should be added to Option<T>

// Insert a value into the `Option`, setting it to `Some(val)` and returning a reference to `val`
fn insert(&mut self, val: T) -> &mut T

// Insert a value into the `Option`, setting it to `Some(val)` and returning a reference to `val`
// along with the previous value in the `Option` (if there was one)
fn insert(&mut self, val: T) -> (&mut T, Option<T>)

[Gankra]

The example code is just a way more verbose version of:

*my_opt = Some(x);
let r = my_opt.as_ref().unwrap();

Still not as clean as

let r = my_opt.insert(x);

But certainly much less dire. I've felt this pain, but I'm not totally sold if it's worth it.

Note also that the code you demonstrate cannot be expressed by insert. Insert takes &mut self, and so any references derived from that input will leave the Option mutably borrowed. Even if you downgrade the &mut output to an &, the Option will still be mutably borrowed.

[canndrew]

The example code is just a way more verbose version of...

D'oh, I didn't think of that. I feel the same way about unwrap as I do about unreachable! though.

Note also that the code you demonstrate cannot be expressed by insert. Insert takes &mut self, and so any references derived from that input will leave the Option mutably borrowed. Even if you downgrade the &mut output to an &, the Option will still be mutably borrowed.

I'm not sure what your point is. Mutably borrowing the Option is the intention.

[Gankra]

Mutably borrowing the Option is the intention.

This is not what your example code does, so this wasn't clear.

[nikomatsakis]

The more general fix to this problem, fwiw, would probably be a combination of the extended enums proposal (so that variants have types) along with a refinement type system that allows us to give more precise, flow-dependent types to mutable references. It would be cool, but certainly not on the short term horizon.

[steveklabnik]

Given #29204 (comment), I'm going to give this a close in favor of an RFC. Thanks!

[hniksic]

To help people who come here via google, don't be misled by this issue being closed and seemingly abandoned - Option::insert() did make it to Rust 1.53. Thanks to people who everyone who contributed!