Cannot move out of borrowed content / cannot move out of behind a shared reference

Question

I don't understand the error cannot move out of borrowed content. I have received it many times and I have always solved it, but I've never understood why.

For example:

for line in self.xslg_file.iter() {
    self.buffer.clear();

    for current_char in line.into_bytes().iter() {
        self.buffer.push(*current_char as char);
    }

    println!("{}", line);
}

produces the error:

error[E0507]: cannot move out of borrowed content
  --> src/main.rs:31:33
   |
31 |             for current_char in line.into_bytes().iter() {
   |                                 ^^^^ cannot move out of borrowed content

In newer versions of Rust, the error is

error[E0507]: cannot move out of `*line` which is behind a shared reference
  --> src/main.rs:31:33
   |
31 |             for current_char in line.into_bytes().iter() {
   |                                 ^^^^ move occurs because `*line` has type `std::string::String`, which does not implement the `Copy` trait

I solved it by cloning line:

for current_char in line.clone().into_bytes().iter() {

I don't understand the error even after reading other posts like:

• Can't borrow File from &mut self (error msg: cannot move out of borrowed content)
• Changing a node in a tree in Rust

What is the origin of this kind of error?

Coquillage

Have you looked at questions like this? (Btw, strings offer the .bytes() method.) – Mandatory

Yes, I looked into it, but didn't understand :( And my string is a std::string::String, according to the documentation, there's no .bytes() method – Coquillage

It's called .as_bytes() – Defendant

In fact, thank you, it works with as_bytes() without cloning. But I still don't understand why ? – Coquillage

String gets the bytes method from str. – Mandatory

Answer 1

Let's look at the signature for into_bytes:

fn into_bytes(self) -> Vec<u8>

This takes self, not a reference to self (&self). That means that self will be consumed and won't be available after the call. In its place, you get a Vec<u8>. The prefix into_ is a common way of denoting methods like this.

I don't know exactly what your iter() method returns, but my guess is that it's an iterator over &String, that is, it returns references to a String but doesn't give you ownership of them. That means you cannot call a method that consumes the value.

As you've found, one solution is to use clone. This creates a duplicate object that you do own, and can call into_bytes on. As other commenters mention, you can also use as_bytes which takes &self, so it will work on a borrowed value. Which one you should use depends on your end goal for what you do with the pointer.

In the larger picture, this all has to do with the notion of ownership. Certain operations depend on owning the item, and other operations can get away with borrowing the object (perhaps mutably). A reference (&foo) does not grant ownership, it's just a borrow.

Why is it interesting to use self instead of &self in a function's arguments?

Transferring ownership is a useful concept in general - when I am done with something, someone else may have it. In Rust, it's a way to be more efficient. I can avoid allocating a copy, giving you one copy, then throwing away my copy. Ownership is also the most permissive state; if I own an object I can do with it as I wish.

---

Here's the code that I created to test with:

struct IteratorOfStringReference<'a>(&'a String);

impl<'a> Iterator for IteratorOfStringReference<'a> {
    type Item = &'a String;

    fn next(&mut self) -> Option<Self::Item> {
        None
    }
}

struct FileLikeThing {
    string: String,
}

impl FileLikeThing {
    fn iter(&self) -> IteratorOfStringReference {
        IteratorOfStringReference(&self.string)
    }
}

struct Dummy {
    xslg_file: FileLikeThing,
    buffer: String,
}

impl Dummy {
    fn dummy(&mut self) {
        for line in self.xslg_file.iter() {
            self.buffer.clear();

            for current_char in line.into_bytes().iter() {
                self.buffer.push(*current_char as char);
            }

            println!("{}", line);
        }
    }
}

fn main() {}

Kidskin

Answer 2

It's frustrating this question was marked as duplicate, because this is another example of a dead-end trap for Rust newbies. It's very hard for a newbie to generalise from these specific answers, which means they just get stuck by the next instance (ref: me).

To provide a little of that generalisation, to help with general "cannot move out of" issues, consider why the issue arose in the first place. There are two primary reasons:

1. You don't want to claim ownership of something.
2. You want to claim ownership of something.

In the first case, you're inadvertently doing something that requires ownership. The solution then, is to find an alternative that doesn't require ownership. This is precisely the case outlined in this question and answer. Instead of into_bytes(), which requires ownership since it consumes its input, substitute with as_bytes() which will do the same thing without claiming ownership.

The reason the solution is not obvious is that the compiler has assumed you really did want to consume line, and helpfully replaced it with *line. Thus, it throws the misleading error, informing you the dereference didn't help. You're left scratching your head about how to fix the inability to move, leading to band-aids like clone().

In fact, you never wanted to dereference in the first place, and just needed to find an alternative that worked with the borrow reference.

Now in the second case (which is the more relevant in the "duplicate" q&a I referenced at the top) the error is the same but you've inadvertently borrowed instead of claiming ownership. This is often the case when implementing a method, since methods typically employ a reference to self rather than consuming it. Incidentally, this is entirely optional - a method can choose to consume rather than borrow self, though I can't imagine this being very practical unless the method returns a Self back.

In this second case, confusingly, a desperate clone() will again appear to solve things, at least in the short term. But given the root causes, the root fix is a bit different. Since you actually do want to claim ownership (perhaps you're trying to drop data, or transfer it to another owner), you need to make that explicit.

In simple cases this might just be a matter of removing the & from wherever you got the variable from - either the return value of a function you called, or as an argument to the current function.

Often you're not able to make that change though. Instead, you have to strip ownership away. But you can't just leave the current owner empty-handed - you need to leave them with something valid. The only way I know of to do this is to use one of take, swap or replace from std::mem. Arriving in 1.40, take is by far the easiest - it simply gives the owner the Default value, and gives you ownership of the current value. The swap and replace alternatives provide the previous owner with something else, which is particularly important if the type doesn't have a Default.

Here's a before and after example:

pub struct SimpleLinkedList<T> {
    head: Option<Box<Node<T>>>
}

pub struct Node<T> {
    value: T,
    next: Option<Box<Node<T>>>
}

impl<T> SimpleLinkedList<T> {
    pub fn pop(&mut self) -> Option<T> {
        if self.head.is_none() { return None; }

        let value = self.head.unwrap().value;
        self.head = self.head.unwrap().next;
        return Some(value);
    }
}

This throws the "cannot move out of self.head which is behind a mutable reference" error, since unwrap() consumes self.

There's lots of ways to improve this, but for illustration purposes, this is all that is necessary:

use std::mem;

pub struct SimpleLinkedList<T> {
    head: Option<Box<Node<T>>>
}

pub struct Node<T> {
    value: T,
    next: Option<Box<Node<T>>>
}

impl<T> SimpleLinkedList<T> {
    pub fn pop(&mut self) -> Option<T> {
        if self.is_empty() { return None; }

        let old_head = mem::take(&mut self.head);
        let old_head_unwrapped = old_head.unwrap();
        self.head = old_head_unwrapped.next;
        return Some(old_head_unwrapped.value);
    }
}

We're replacing the self.head value anyway, so by calling take on it we can claim ownership. We're then free to pass it to unwrap() and subsequently overwrite the original self.head.

So in conclusion, why do you get "cannot move out of borrowed content/reference"? Either because you only need to borrow and must ensure whatever you do never consumes, or because you actually want to consume and must take ownership.

Woolf