Understanding move semantics for enums Rust

Question

So I'm looking at the impl for is_some() for Option and I noticed that it uses match *self {} under the hood...so it moves it internally.

My question is, if it gets moved, how am I able to do something like this? https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f094da12290b77bad526674467e51043

fn main() {
    let x = Option::Some(3);
    x.is_some();
    x.is_some();
}

My expectation is that I should be able to call is_some() only once, and the next time I call it I should get some sort of error saying it's been moved...but no, it all compiles fine.

What am I misunderstanding?

Answer 1

*self in match *self { ... } does not move (or copy) what self points to. From "The Rust Reference" (emphasis mine),

A match behaves differently depending on whether or not the scrutinee expression is a place expression or value expression. If the scrutinee expression is a value expression, it is first evaluated into a temporary location, ...

When the scrutinee expression is a place expression, the match does not allocate a temporary location; however, a by-value binding may copy or move from the memory location. ...

*self is a place expression. From "The Rust Reference" (emphasis mine),

Expressions are divided into two main categories: place expressions and value expressions. ...

A place expression is an expression that represents a memory location. These expressions are paths which refer to local variables, static variables, dereferences (*expr), array indexing expressions (expr[expr]), field references (expr.f) and parenthesized place expressions. All other expressions are value expressions.

A value expression is an expression that represents an actual value.

---

You might also be interested to know that the Some(_) => true arm in the match body does not bind anything. From "The Rust Reference",

Unlike identifier patterns, it does not copy, move or borrow the value it matches.

where "it" means the wildcard pattern (_).

Answer 2

(See the @dkim's answer for a more official and cited answer)

If the signature of the function accepts by reference, it does not take ownership of the value. Option.is_some() actually takes &self not self.

The interesting part is how *self is allowed to be used in a function that receives &self when Self: Copy is not bounded.

To test this, let's create a minimal example containing something similar: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=d7b137b74b5cd8f8bb57398ae01bf4e3

#[derive(Debug)]
pub enum A {
    X(String),
    Y(i32),
}
pub fn f(a: &A) {
    match *a {
        A::X(_) => {
            //  dbg!(s);
        }
        A::Y(_i) => {
            //  dbg!(i);
        }
    };
}

This compiles fine. But let's change the A::X(_) pattern to A::X(_s): https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=93030e5c3f84532532c5db966c798bd6

#[derive(Debug)]
pub enum A {
    X(String),
    Y(i32),
}
pub fn f(a: &A) {
    match *a {
        A::X(_s) => {
            //  dbg!(s);
        }
        A::Y(_i) => {
            //  dbg!(i);
        }
    };
}

This fails to compile:

error[E0507]: cannot move out of `a.0` which is behind a shared reference
 --> src/lib.rs:7:11
  |
7 |     match *a {
  |           ^^ help: consider borrowing here: `&*a`
8 |         A::X(_s) => {
  |              --
  |              |
  |              data moved here
  |              move occurs because `_s` has type `std::string::String`, which does not implement the `Copy` trait

So it appears that dereferencing a non-Copy enum is perfectly fine, as long as it wouldn't be used for moving inner non-Copy values. _ is fine because it guarantees that the underlying value would never be used, while _s does not compile because it is just a normal allow(unused) variable.

This also makes sense because it allows the same match arm to work on both Copy and non-Copy types, as long as no usages violate the ownership rules