クロージャ間で変数を共有できない場合にCellを使うのは適当か

Question

前提

あるプログラムを作りました。
エラーが出てコンパイルできませんでしたが、Cellを使うとコンパイルできました。
動作はgetもsetも常に成功するようで問題なさそうです。

コンパイルはできましたが、この場面でCell、内部可変性を使うのが適当なのかわかっていません。
適当でしょうか？
適当ではない場合、Cellを使わないでよい方法はありますか？

実現したいこと

こういったコード

• 入力がイテレータ(impl Iterator)
• 入力イテレータが出す値を基本的には順番に別の関数へ渡し、その値の処理結果が得られるイテレータを得る
  • このイテレータが出す値を最終的にVecにまとめる
  • このイテレータが出す値によっては、入力イテレータが出す残りの要素を、特定の条件を満たすまで無視する

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

Cellを使わないときのコンパイルエラー

error: captured variable cannot escape `FnMut` closure body
  --> src/main.rs:70:9
   |
56 |     let mut next_start = 0; // 無視する条件にかかわる変数
   |         -------------- variable defined here
57 |     
58 |     let main_result = iter::from_fn(|| {
   |                                      - inferred to be a `FnMut` closure
59 |         let start = std::mem::take(&mut next_start);
   |                                         ---------- variable captured here
...
70 |         Some(process_line(input_line).inspect(|(end, _)| { next_start = *end; }))
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ returns a reference to a captured variable which escapes the closure body
   |
   = note: `FnMut` closures only have access to their captured variables while they are executing...
   = note: ...therefore, they cannot allow references to captured variables to escape

該当のソースコード

元のコードより簡略化したものです。
Cellを使うメイン処理（コメントアウト）と使わないメイン処理の両方を書いてあります。
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=92ff444fb49504859dd6d767c9a575b9

試したこと

コンパイルが通るように色々試す

Answer 1

クロージャ間で変数を共有できない場合にCellを使うのは適当か

Cellは実行時に僅かなオーバーヘッドがあるのと、 借用ルールに違反した場合はコンパイルエラーではなく実行時エラー（panic）になるので、 もし使わないですむなら使わないほうがいいです。（2022年10月5日 訂正：コメント欄でご指摘いただいたとおりCellがpanicするというのは誤りでした。Cellはpanicしないのが正しいです。RefCellと混同してしまいました）

しかし、今回の質問のようなコードで変数を共有するにはCellしかなさそうですので、Cellを使うのは適当だと思います。

余談ですが、ご質問のコードで試したところ、片方のクロージャーを構造体で置き換え、その構造体にIteratorを実装することで、 Cellを使わずに同じ機能を実現できました。簡略化前のコードに適用できるかはわかりませんが、参考になるかもしれません。

2022年10月5日 訂正：コメント欄でご指摘いただいたとおり、うまく動く理由はMyIter::next内でcollectしているためでした。collectせず、Iterator::Itemをimpl Iteratorにすると、おっしゃる通り、inspectのクロージャーが &mut next_start をキャプチャ（捕捉）しようとするので、元のコードと同じ所有権がらみのエラーになってしまいました。

#[derive(Debug, Clone, PartialEq, Eq)]
enum Line2 {
    A,
    B,
}

// クロージャーとiter::from_fn()で作っていたイテレーターを構造体で置き換える
struct MyIter<I1, F> {
    lines: I1,
    process_line: F,
    next_start: i32,
}

impl<I1, F, I2> Iterator for MyIter<I1, F>
where
    I1: Iterator<Item = i32>,          // linesイテレーター
    F: FnMut(i32) -> I2,               // process_lineクロージャー
    I2: Iterator<Item = (i32, Line2)>, // process_lineの戻り値（イテレーター）
{
    type Item = Vec<(i32, Line2)>;

    fn next(&mut self) -> Option<Self::Item> {
        let input_line = loop {
            let input_line = self.lines.next()?;
            if input_line >= self.next_start {
                break input_line;
            }
            println!("{}: skipped", input_line);
        };
        println!("{}: processed", input_line);

        Some((self.process_line)(input_line)
            .inspect(|(end, _)| { self.next_start = *end; })
            .collect()
        )
    }
}

fn main() {
    // process_line の出力用
    let mut process_line_results = [
        (0, &[(1, Line2::A), (1, Line2::B)][..]),
        (1, &[]),
        (2, &[(4, Line2::B)]),
        // 3 はなし、4 まで飛ばすので飛ばされる
        (4, &[]),
        (5, &[(6, Line2::A)]),
    ]
    .into_iter();

    // 行の内容を処理して結果を返す処理
    // ここでは process_line_results から順番に返すようにしている
    // ここではクロージャだが、実際は関数
    // 実際も戻り値は impl Iterator
    let process_line = |i| {
        // 計5回呼ばれる
        let (expected_i, line_items) = process_line_results.next().unwrap();
        assert_eq!(i, expected_i);
        line_items.into_iter().cloned() // impl Iterator<Item=(i32, Line2)>
    };

    // 入力データ
    // ここでは単なる数値 [0,1,2,3,4,5]
    // 実際も impl Iterator
    let lines = 0..6_i32;

    // ★メイン処理
    let main_result = MyIter {
        lines,
        process_line,
        next_start: 0,
    }
    .flatten()
    .collect::<Vec<_>>();

    // 処理結果出力
    println!("main_result: {:?}", main_result);
    assert_eq!(
        main_result,
        vec![(1, Line2::A), (1, Line2::B), (4, Line2::B), (6, Line2::A),]
    );
}

2022年10月5日 追記

所有権の問題を回避するために、MyIter::nextがイテレーター（impl Iterator<Item=(i32, Line2)>）を返すのではなく、(i32, Line2)を返す実装にしてみました。

ただ、ここまでするなら、MyIterをイテレーターにしてmainでcollectするよりも、イテレーターにせずにVec<(i32, Line2)>を返すメソッドを作る方が簡単かもしれません。

#[derive(Debug, Clone, PartialEq, Eq)]
enum Line2 {
    A,
    B,
}

// クロージャーとiter::from_fn()で作っていたイテレーターを構造体で置き換える
struct MyIter<I1, F, I2> {
    input_lines_iter: I1,
    process_line: F,
    processed_lines_iter: Option<I2>,
    next_start: i32,
}

impl<I1, F, I2> MyIter<I1, F, I2> {
    fn new(input_lines_iter: I1, process_line: F) -> Self {
        MyIter {
            input_lines_iter,
            process_line,
            processed_lines_iter: None,
            next_start: 0,
        }
    }
}

impl<I1, F, I2> Iterator for MyIter<I1, F, I2>
where
    I1: Iterator<Item = i32>,          // input_linesイテレーター
    F: FnMut(i32) -> I2,               // process_lineクロージャー
    I2: Iterator<Item = (i32, Line2)>, // process_lineの戻り値
{
    type Item = (i32, Line2);          // このイテレーターの戻り値型

    fn next(&mut self) -> Option<Self::Item> {
        loop {
            // process_lineの戻り値のイテレーターがないなら、process_lineを呼び出して
            // イテレーターを作る
            if self.processed_lines_iter.is_none() {
                let input_line = loop {
                    let input_line = self.input_lines_iter.next()?;
                    if input_line >= self.next_start {
                        break input_line;
                    }
                    println!("{}: skipped", input_line);
                };
                println!("{}: processed", input_line);

                self.processed_lines_iter = Some((self.process_line)(input_line));
            }

            if let Some(pl_iter) = &mut self.processed_lines_iter {
                // process_lineの戻り値のイテレーターから次の値を取り出す
                if let Some(pl @ (end, _)) = pl_iter.next() {
                    self.next_start = end;
                    return Some(pl);
                } else {
                    // イテレーターが終了していたら、最初からやり直す
                    self.processed_lines_iter = None;
                    continue;
                }
            } else {
                // 全ての行を処理したので終了する
                return None;
            }
        }
    }
}

fn main() {
    // process_line の出力用
    let mut process_line_results = [
        (0, &[(1, Line2::A), (1, Line2::B)][..]),
        (1, &[]),
        (2, &[(4, Line2::B)]),
        // 3 はなし、4 まで飛ばすので飛ばされる
        (4, &[]),
        (5, &[(6, Line2::A)]),
    ]
    .into_iter();

    // 行の内容を処理して結果を返す処理
    // ここでは process_line_results から順番に返すようにしている
    // ここではクロージャだが、実際は関数
    // 実際も戻り値は impl Iterator
    let process_line = |i| {
        // 計5回呼ばれる
        let (expected_i, line_items) = process_line_results.next().unwrap();
        assert_eq!(i, expected_i);
        line_items.into_iter().cloned() // impl Iterator<Item=(i32, Line2)>
    };

    // 入力データ
    // ここでは単なる数値 [0,1,2,3,4,5]
    // 実際も impl Iterator
    let lines = 0..6_i32;

    // ★メイン処理
    // flattenが不要になった
    let main_result = MyIter::new(lines, process_line).collect::<Vec<_>>();

    // 処理結果出力
    println!("main_result: {:?}", main_result);
    assert_eq!(
        main_result,
        vec![(1, Line2::A), (1, Line2::B), (4, Line2::B), (6, Line2::A),]
    );
}

Comments

[trrk]

回答ありがとうございます！
僅かなオーバーヘッドがあるため`Cell`を使わないですむなら使わないほうがよいが、今回のようなケースでは使うのが妥当と考えられる、と理解しました。

panic周りは、こう認識しています。
・`Cell`はpanicしない
・`RefCell`は実行時に借用ルールの検査があり、panicしうる
これが正しいと考えているのですが、いただいた回答と食い違っており、この点は気になっています。
（もしかしたら`Cell`と`RefCell`を混同されただけかもしれません。）

余談もありがとうございます。簡略化前のコードにも適用できました。
また、構造体を使ったIteratorの実装方法など、参考になりました。

余談です。
ただ、コンパイルできるようになったのはinspectの後に一度collectを挟んだためのようでした。
元のコードでも、同じようにcollectをするとコンパイルできました。

collectせずにできないか試したのですが、これは無理そうでした。
MyIterのItemをimpl Iteratorにするのはunstableで、これを有効化してもnextからMyIter自身へのライフタイム?(inspectのクロージャからnext_startへアクセスするために参照が必要?)を含む戻り値を返せずに詰みました。そのため、Cellを使う形で落ち着きそうです。
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=2f5d66c46e43315a4dd3b281a8017f2d

[tatsuya6502]

返信が遅くなりました。おっしゃる通り、私の回答が間違っていました。正しくは、(1) Cellはpanicしない、(2) 余談のコードがうまくいくのはcollectのおかげ、となります。

MyIterのItemをimpl Iteratorにするのを、私の方でも試してみましたが、やはり所有権がらみのエラーになり、詰みました。

一応、さらに余談として、MyIter::nextがイテレーターを返すのではなく、(i32, Line2)を返すようにした例を追記しました。MyIterの中で、process_lineが返したイテレーターを直接操ることで所有権の問題を回避しています。

[trrk]

いえ、編集してくださってありがとうございます。誤りだったのですね。

Itemを(i32, Line2)としたIteratorを試すと、簡略化前のコードでも有効でした！　この実装は思いつきませんでした。確かにcollectを使ったほうが簡単そうですが、個人的になるべくcollectしたくありませんでしたし、collectもCellも使わない実装方法が知れてよかったです。