13

I'm tring to replace a value in a mutable borrow; moving part of it into the new value:

enum Foo<T> {
    Bar(T),
    Baz(T),
}

impl<T> Foo<T> {
    fn switch(&mut self) {
        *self = match self {
            &mut Foo::Bar(val) => Foo::Baz(val),
            &mut Foo::Baz(val) => Foo::Bar(val),
        }
    }
}

The code above doesn't work, and understandibly so, moving the value out of self breaks the integrity of it. But since that value is dropped immediately afterwards, I (if not the compiler) could guarantee it's safety.

Is there some way to achieve this? I feel like this is a job for unsafe code, but I'm not sure how that would work.

azgult
  • 542
  • 3
  • 10
  • 1
    If you add a `Copy` bound to `T`, your code actually works, although I obviously don't know if you're ok with that restriction. – fjh Apr 10 '15 at 21:44

3 Answers3

10

mem:uninitialized has been deprecated since Rust 1.39, replaced by MaybeUninit.

However, uninitialized data is not required here. Instead, you can use ptr::read to get the data referred to by self.

At this point, tmp has ownership of the data in the enum, but if we were to drop self, that data would attempt to be read by the destructor, causing memory unsafety.

We then perform our transformation and put the value back, restoring the safety of the type.

use std::ptr;

enum Foo<T> {
    Bar(T),
    Baz(T),
}

impl<T> Foo<T> {
    fn switch(&mut self) {
        // I copied this code from Stack Overflow without reading
        // the surrounding text that explains why this is safe.
        unsafe {
            let tmp = ptr::read(self);
    
            // Must not panic before we get to `ptr::write`

            let new = match tmp {
                Foo::Bar(val) => Foo::Baz(val),
                Foo::Baz(val) => Foo::Bar(val),
            };
    
            ptr::write(self, new);
        }
    }
}

More advanced versions of this code would prevent a panic from bubbling out of this code and instead cause the program to abort.

See also:

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
7

The code above doesn't work, and understandibly so, moving the value out of self breaks the integrity of it.

This is not exactly what happens here. For example, same thing with self would work nicely:

impl<T> Foo<T> {
    fn switch(self) {
        self = match self {
            Foo::Bar(val) => Foo::Baz(val),
            Foo::Baz(val) => Foo::Bar(val),
        }
    }
}

Rust is absolutely fine with partial and total moves. The problem here is that you do not own the value you're trying to move - you only have a mutable borrowed reference. You cannot move out of any reference, including mutable ones.

This is in fact one of the frequently requested features - a special kind of reference which would allow moving out of it. It would allow several kinds of useful patterns. You can find more here and here.

In the meantime for some cases you can use std::mem::replace and std::mem::swap. These functions allow you to "take" a value out of mutable reference, provided you give something in exchange.

Vladimir Matveev
  • 120,085
  • 34
  • 287
  • 296
  • It makes little sense for me to require the caller of the method to own `Foo`, when it is possible to implement it using only a `&mut`. Ownership shouldn't be required in this case, as the integrity of `self` can be guaranteed. – azgult Apr 10 '15 at 22:14
  • @azgult and that's exactly the reason why a lot of people request `&own`-like pointer (see the links to RFC and issue I provided) - because such thing in fact *do* require ownership (*only* owner can move values around). – Vladimir Matveev Apr 10 '15 at 22:19
4

Okay, I figured out how to do it with a bit of unsafeness and std::mem.

I replace self with an uninitialized temporary value. Since I now "own" what used to be self, I can safely move the value out of it and replace it:

use std::mem;

enum Foo<T> {
    Bar(T),
    Baz(T),
}

impl<T> Foo<T> {
    fn switch(&mut self) {
        // This is safe since we will overwrite it without ever reading it.
        let tmp = mem::replace(self, unsafe { mem::uninitialized() });
        // We absolutely must **never** panic while the uninitialized value is around!

        let new = match tmp {
            Foo::Bar(val) => Foo::Baz(val),
            Foo::Baz(val) => Foo::Bar(val),
        };

        let uninitialized = mem::replace(self, new);
        mem::forget(uninitialized);
    }
}

fn main() {}
Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
azgult
  • 542
  • 3
  • 10
  • 4
    This program will fail horribly if `T` has destructor. When you call `swap` you're replacing whatever is located at `self` with garbage. Then you reassign `*self`, and Rust will insert a call to destructor which would attempt to destroy the "old" value of `*self`, which is now garbage. For some reason [playpen](http://is.gd/uaIhEe) does not fail (but you can see double free there), but for me that program core dumps when I compile and run it locally. – Vladimir Matveev Apr 10 '15 at 22:26
  • 1
    [This](http://is.gd/yT03vG) program more clearly demonstrates when and how a destructor is called. If your program was safe, it would be called only once, but it is called twice - the first time being erroneous. – Vladimir Matveev Apr 10 '15 at 22:31
  • Good catch. I believe that the modified version which uses `std::ptr::write` should be safe however. – azgult Apr 10 '15 at 22:41
  • 1
    no it's not safe, now you are actually dropping uninitialized memory. You need to `mem::forget` the `tmp` variable after the `write` call – oli_obk Nov 06 '15 at 09:23
  • @oli_obk-ker I rewrote the answer based on these comments because it was being linked to; how does it look now? – Shepmaster Sep 16 '17 at 20:05
  • @VladimirMatveev I rewrote the answer based on these comments because it was being linked to; how does it look now? – Shepmaster Sep 16 '17 at 20:05
  • 2
    [`take`](https://docs.rs/take_mut/0.2.0/take_mut/fn.take.html) shows how to do this in a generic way, and also protects against unwinding (aborts instead). – Stefan Nov 25 '17 at 15:30