When would an implementation want to take ownership of self in Rust?

Question

I'm reading through the Rust documentation on lifetimes. I tried something like:

struct S {
    x: i8,
}

impl S {
    fn fun(self) {}

    fn print(&self) {
        println!("{}", self.x);
    }
}

fn main() {
    let s = S { x: 1 };
    s.fun();
    s.print();
}

I get the following error:

error[E0382]: borrow of moved value: `s`
  --> src/main.rs:16:5
   |
15 |     s.fun();
   |     - value moved here
16 |     s.print();
   |     ^ value borrowed here after move
   |
   = note: move occurs because `s` has type `S`, which does not implement the `Copy` trait

This is because the fun(self) method takes ownership of the s instance. This is solved by changing to fun(&self).

I can't see why you would ever want to have a method on an object take control of itself. I can think of only one example, a destructor method, but if you wanted to do dispose of the object then it would be taken care of by the owner of the object anyway (i.e. scope of main in this example).

Why is it possible to write a method that takes ownership of the struct? Is there ever any circumstance where you would want this?

Answer 1

The idiomatic way to refer to a method that "takes control" of self in the Rust standard library documentation is to say that it "consumes" it. If you search for this, you should find some examples:

• Option::unwrap_or_default
• A lot in the Iterator trait.

As to why: you can try rewriting Iterator::map — you would end up having a lifetime parameter wandering around that would quickly become unmanageable. Why? Because the Map iterator is based upon the previous one, so the borrow checker will enforce that you can only use one of the two at the same time.

Answer 2

Conversion from type A to type B commonly involves functions taking self by value. See the implementors of Into and From traits for concrete examples.