mutable関連のコンパイルエラーの原因が分からない

Question

前提

Rustを始めたのですが、mutable関連のコンパイルエラーが発生して詰まってしまったので、詳しい人に原因を教えてもらいたいです。

実現したいこと

• コンパイルエラーの原因を知る

発生している問題・エラーメッセージ

error[E0502]: cannot borrow `self.item` as mutable because it is also borrowed as immutable
  --> src/sandbox.rs:22:13
   |
20 |             player.play();
   |             ------------- immutable borrow later used here
21 |
22 |             self.item.change();
   |             ^^^^^^^^^^^^^^^^^^ mutable borrow occurs here
...
25 |                 player = self.get_next_player();
   |                          ---------------------- immutable borrow occurs here

該当のソースコード

問題が発生する箇所から、余計なものを取り除き、エラーが起きる最小限のコードにしたものです。
（最小限にしたので無限ループになってしまいましたが、本来はbreakする箇所があります）

struct Item {}
impl Item {
    fn change(&mut self) {}
}

struct Player {}
impl Player {
    fn play(&self) {}
}

struct Sandbox {
    item: Item,
    player: Player,
}
impl Sandbox {
    pub fn start(&mut self) {
        let mut player = &self.player;

        while true {
            player.play();

            // ここでコンパイルエラーが発生する
            self.item.change();

            if true {
                player = self.get_next_player();
            }
        }
    }

    fn get_next_player(&self) -> &Player {
        &self.player
    }
}

試したこと

エラーメッセージを和訳するとself.itemはimuutableとしても借用されているので、mutableとして借用できないとのことですが、self.itemが使われている箇所は１箇所しかなく、意味が分かりませんでした。

また、以下のようにコードに色々手を加えるとエラーが起きなくなるのですが、いずれも何故そうなるのか分かりませんでした。

以下の行どれか１つを消す

• player.play();
• self.item.change();
• player = self.get_next_player();

なぜかこの３つが全て揃ってないとエラーになりません。

get_next_player() を消す

self.get_next_player() をやめて、代わりに&self.playerにするとエラーが起きません。

if 文を消す

if文を消してplayer = self.get_next_player();を外に出すとエラーが起きません。

playerへの代入を止める

player = を消して、self.get_next_player(); だけにするとエラーが起きません。

追記1

その後、思い当たった仮説を追記。

そももの原因は、self.get_next_player()のところで、selfがimmutable借用された後、self.item.change()でmuttable借用されるから？

player.play()、player = self.get_next_player()を書き換えたときエラーが起きなくなるのは、Non-lexical lifetimesの機能によって、コンパイラーがplayerにselfが借用されてないと判定されている？

ただ、if文を消すとエラーにならない原因は分からない。

補足情報（FW/ツールのバージョンなど）

rustc 1.65.0 (897e37553 2022-11-02)

Answer 1

自己レスですが、if trueを消すとエラーが出なくなる点については、コンパイラーによって、以下のように判定されているのではないかと思います。

// 1. まず、ここでselfがplayer変数にimmutable借用される
let mut player = &self.player;

while true {
    player.play();

    // 2. 次にここでselfがmutable借用されるが、既に1でimmutable借用されているのでエラーになる
    self.item.change();

    // 3. ここでplayerが上書きされると、以降1のplayer参照は使われないので、2のmutable借用が問題なくなる。
    // そのためif文がないとエラーにならないが、if文があると常に上書きされないとみなされてエラーになる
    if true {
        player = self.get_next_player();
    }

   // 仮に上のifブロックに入らなかったとすると、次のループで1のplayer参照が使われるので、2は不味いということになる
}

Answer 2

同じような現象を再現する更に簡略化した例を作りました。

struct Foo {
    x: u32,
    y: u32
}

impl Foo {
    fn new(x: u32, y: u32) -> Foo {
        Foo { x,y }
    }

    fn x_ref(&self) -> &u32 {
        &self.x
    }
}

fn main() {
    let mut a = Foo::new(1,2);
    let b = a.x_ref();
    let c = &mut a.y;
    println!("{}{}", b,c);
}

同じようなエラーが出ます。

error[E0502]: cannot borrow `a.y` as mutable because it is also borrowed as immutable
  --> prog.rs:19:13
   |
18 |     let b = a.x_ref();
   |             - immutable borrow occurs here
19 |     let c = &mut a.y;
   |             ^^^^^^^^ mutable borrow occurs here
20 |     println!("{}{}", b,c);
   |                      - immutable borrow later used here

---

このとき

fn x_ref(&self) -> &u32 {
    &self.x
}

にはライフタイムの指定を書いておりませんがこれはよくあるパターンは自動的に補われるようになっているからです。 実際には

fn x_ref<'a>(&'a self) -> &'a u32 {
    &self.x
}

のように解釈されています。 この関数 x_ref の入出力の間の依存関係が出来上がり、出力結果である参照が存在する限り &self としてオブジェクト全体も借用している状態です。

---

そしてオブジェクト全体が借用されているとき、そのオブジェクトのメンバの借用にも影響が出ます。 (逆にメンバの借用がそれを含むオブジェクトの借用に影響することもあります。) オブジェクトの mut 参照が制限されているときにメンバの mut 参照が許されるのだと整合性が取れないというのは感覚的にもわかるかと思います。

ここで a.y 自体は借用されていませんけども a の借用があることによって a.y に制限がかかってしまうのです。

---

この例で

println!("{}{}", b,c);

の部分を削除すると &mut a.y; は可能になります。 変数の寿命は通常はスコープの終わりなのですが、使われないことがわかっているときは早めに寿命を終えることがあるからです。 b が使われないことを処理系が看破したらその場で借用を終えてしまうのでそれに依存している a の借用も消えて新たな借用が可能になります。

---

質問の事例に当てはめると、

• player = self.get_next_player(); → self 全体が借用されていることになる
• self.item.change(); → self が借用されている影響で self.item が制限される
• player.play(); → player を実際に使うことによって早目に寿命を終えることを許さない

ということになります。

私自身が正確な仕様を理解しているわけではありませんが大まかに関連するルールとしてはたぶん外してないと思います。

Comments

[rim_yamamoto]

丁寧な回答ありがとうございます。

> ここで a.y 自体は借用されていませんけども a の借用があることによって a.y に制限がかかってしまうのです。

この点を理解していませんでした。

if trueを消すとエラーが出なくなる点については、改めて考えて整理がついたので、そちらも回答に記載しておきます。何かツッコミどころがあればコメントお願いいたします。