Day 016 — Iteratorトレイトとイテレータアダプタ

📚 背景知識（読んでから問題へ）

Rustのforループ・map/filter/foldといったコレクション操作は、すべてstd::iter::Iteratorトレイトという単一のインターフェースの上に成り立っています。

📋 コピーpub trait Iterator {
    type Item;
    fn next(&mut self) -> Option<Self::Item>;
    // map, filter, fold, sum, collect などはすべて Item と next() から
    // デフォルト実装として提供される（実装必須なのは next() だけ）
}

重要なのは、Iteratorが要求するメソッドは実質next()ただ1つだけだという点です。map・filter・fold・sum・collectなど数十個のメソッドは、すべてnext()の呼び出しを組み合わせたデフォルト実装として標準ライブラリ側に用意されています。1つのコア機能から膨大な機能群を導出する、トレイトのデフォルト実装を極限まで活用した設計です。

イテレータアダプタと消費アダプタの違いが、このテーマ最大のポイントです。

• アダプタ（adapter）: map・filter・enumerate・zip・take_while・skip_while・chainなど。イテレータを受け取り、新しいイテレータを返す。呼び出した時点では何も実行されない（遅延評価/lazy）
• 消費アダプタ（consumer）: collect・sum・fold・for_each・countなど。イテレータのnext()を実際に呼び出し尽くして値を取り出す。呼び出した瞬間に初めて処理が走る（eager）

📋 コピーlet v = vec![1, 2, 3, 4, 5];
let iter = v.iter().map(|x| x * 2).filter(|x| x % 3 == 0);
// ↑ この行だけでは何も計算されていない。iterは「計算のレシピ」を持つ値
let result: Vec<i32> = iter.collect();
// ↑ collect() が呼ばれた瞬間に初めて next() が連鎖的に呼ばれ、計算が実行される

この遅延評価の仕組みにより、Rustのイテレータチェーンはコンパイラの最適化（LLVM）によって手書きのforループと同等かそれ以上の機械語に展開されることが多く、「高レベルな書き方をしても実行時コストがゼロ」というゼロコスト抽象化の代表例になっています。中間コレクション（Vecなど）を一切ヒープに確保せず、要素ごとにmap→filter→次の要素…と1個ずつパイプライン的に処理されるのが、多くの他言語のコレクションAPI（一段階ごとに新しい配列を作る実装）との決定的な違いです。

IntoIteratorトレイトも押さえておきます。for x in collectionという構文は、collection.into_iter()を呼び出す糖衣構文です。.iter()（&Tを返す・借用）、.iter_mut()（&mut Tを返す・可変借用）、.into_iter()（Tを返す・所有権を移動）という3種類の使い分けが、Rustの所有権システムがコレクション走査にまで一貫して及んでいることを示しています。

📝 問題

以下の4つの要求に順番に答えてください。

要求1（実装: 基本のアダプタ連鎖）

Transaction { amount: i64, category: String, is_valid: bool }という構造体を定義し、&[Transaction]を受け取って有効な（is_valid == true）取引の合計金額を返す関数total_valid_amountを、filter・map・sumの連鎖のみで（forループを使わずに）実装してください。

要求2（実装: enumerate と zip）

2つの&[i32]スライスa・b（同じ長さとは限らない）を受け取り、同じインデックスの値が一致している位置のインデックス一覧をVec<usize>で返す関数matching_indicesを、zip・enumerate・filter・mapの連鎖で実装してください。

要求3（実装: 遅延評価の実証）

イテレータアダプタが呼び出し時点では実行されず、消費アダプタが呼ばれて初めて実行されることを、std::cell::Cell<u32>を使ったカウンタで実証するテストを書いてください。具体的には、mapのクロージャ内でカウンタをインクリメントし、①mapを呼んだ直後はカウンタが0のまま、②collect()した後はカウンタが要素数と一致すること、の両方をassert_eq!で検証してください。

要求4（実装: ジェネリックなイテレータ受け取り関数）

impl Iterator<Item = i64>というトレイト境界を使ったジェネリック関数として、次の2つを実装してください。

• sum_until_threshold(iter: impl Iterator<Item = i64>, threshold: i64) -> i64: take_whileでthreshold未満の要素だけを取り、その合計を返す
• combined_sum(a: impl Iterator<Item = i64>, b: impl Iterator<Item = i64>) -> i64: chainで2つのイテレータを連結し、その合計を返す

これらの関数がVecの.into_iter()だけでなく、Range（0..10など）のような別の型のイテレータもそのまま渡せることをテストで示してください。

🔍 ヒント（段階的開示）

📋 コピーuse std::cell::Cell;

struct Transaction {
    amount: i64,
    category: String,
    is_valid: bool,
}

fn total_valid_amount(transactions: &[Transaction]) -> i64 {
    transactions
        .iter()
        .filter(|t| t.is_valid)
        .map(|t| t.amount)
        .sum()
}

fn matching_indices(a: &[i32], b: &[i32]) -> Vec<usize> {
    a.iter()
        .zip(b.iter())
        .enumerate()
        .filter(|(_, (x, y))| x == y)
        .map(|(i, _)| i)
        .collect()
}

fn sum_until_threshold(iter: impl Iterator<Item = i64>, threshold: i64) -> i64 {
    iter.take_while(|&x| x < threshold).sum()
}

fn combined_sum(a: impl Iterator<Item = i64>, b: impl Iterator<Item = i64>) -> i64 {
    a.chain(b).sum()
}

✅ 模範解答

📋 コピーuse std::cell::Cell;

// 要求1: Transaction と total_valid_amount
struct Transaction {
    amount: i64,
    #[allow(dead_code)]
    category: String,
    is_valid: bool,
}

fn total_valid_amount(transactions: &[Transaction]) -> i64 {
    transactions
        .iter()
        .filter(|t| t.is_valid)
        .map(|t| t.amount)
        .sum()
}

// 要求2: matching_indices
fn matching_indices(a: &[i32], b: &[i32]) -> Vec<usize> {
    a.iter()
        .zip(b.iter())
        .enumerate()
        .filter(|(_, (x, y))| x == y)
        .map(|(i, _)| i)
        .collect()
}

// 要求4: impl Iterator<Item = i64> を境界に取るジェネリック関数
fn sum_until_threshold(iter: impl Iterator<Item = i64>, threshold: i64) -> i64 {
    iter.take_while(|&x| x < threshold).sum()
}

fn combined_sum(a: impl Iterator<Item = i64>, b: impl Iterator<Item = i64>) -> i64 {
    a.chain(b).sum()
}

fn main() {
    // 要求1の実行例
    let transactions = vec![
        Transaction { amount: 1000, category: "food".to_string(), is_valid: true },
        Transaction { amount: 500, category: "book".to_string(), is_valid: false },
        Transaction { amount: 2000, category: "rent".to_string(), is_valid: true },
    ];
    println!("total_valid_amount = {}", total_valid_amount(&transactions)); // 3000

    // 要求2の実行例
    let a = [1, 2, 3, 4, 5];
    let b = [1, 9, 3, 9, 5];
    println!("matching_indices = {:?}", matching_indices(&a, &b)); // [0, 2, 4]

    // 要求4の実行例: Vec と Range のどちらも同じ関数に渡せる
    let v = vec![10_i64, 20, 30, 100, 200];
    println!("sum_until_threshold(v) = {}", sum_until_threshold(v.into_iter(), 50)); // 60
    println!("sum_until_threshold(range) = {}", sum_until_threshold(0..100_i64, 10)); // 45
    println!("combined_sum = {}", combined_sum(vec![1, 2, 3].into_iter(), (10..13).into_iter())); // 6+33=39
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn total_valid_amount_sums_only_valid_transactions() {
        let transactions = vec![
            Transaction { amount: 1000, category: "food".to_string(), is_valid: true },
            Transaction { amount: 500, category: "book".to_string(), is_valid: false },
            Transaction { amount: 2000, category: "rent".to_string(), is_valid: true },
        ];
        assert_eq!(total_valid_amount(&transactions), 3000);
    }

    #[test]
    fn matching_indices_finds_equal_positions_with_shorter_length() {
        let a = [1, 2, 3, 4, 5];
        let b = [1, 9, 3, 9]; // aより短い。zipはbの長さに揃わる
        assert_eq!(matching_indices(&a, &b), vec![0, 2]);
    }

    // 要求3: 遅延評価の実証
    #[test]
    fn iterator_adapters_are_lazy_until_consumed() {
        let counter = Cell::new(0u32);
        let data = vec![1, 2, 3, 4, 5];

        let iter = data.iter().map(|x| {
            counter.set(counter.get() + 1);
            x * 2
        });

        // ① map を呼んだ直後: クロージャは1回も実行されていない
        assert_eq!(counter.get(), 0);

        // ② collect() で初めて next() が5回呼ばれ、クロージャも5回実行される
        let result: Vec<i32> = iter.collect();
        assert_eq!(counter.get(), 5);
        assert_eq!(result, vec![2, 4, 6, 8, 10]);
    }

    #[test]
    fn take_while_short_circuits_and_does_not_process_remaining_elements() {
        let counter = Cell::new(0u32);
        let data = vec![1, 2, 3, 100, 4, 5]; // 100 で take_while が止まるはず

        let result: Vec<i32> = data
            .iter()
            .map(|x| {
                counter.set(counter.get() + 1);
                *x
            })
            .take_while(|&x| x < 10)
            .collect();

        assert_eq!(result, vec![1, 2, 3]);
        // 100 を処理した時点で take_while が止まるため、後続の 4, 5 は map にすら渡らない
        assert_eq!(counter.get(), 4); // 1, 2, 3, 100 の4要素分だけ実行される
    }

    // 要求4: Vec と Range のどちらでも同じ関数が使えることの確認
    #[test]
    fn generic_iterator_functions_accept_different_iterator_types() {
        let from_vec = sum_until_threshold(vec![10_i64, 20, 30, 100].into_iter(), 50);
        assert_eq!(from_vec, 60);

        let from_range = sum_until_threshold(0..100_i64, 10);
        assert_eq!(from_range, 45); // 0+1+...+9 = 45

        let combined = combined_sum(vec![1_i64, 2, 3].into_iter(), 10..13);
        assert_eq!(combined, 6 + 33); // (1+2+3) + (10+11+12)
    }
}

$ cargo run
total_valid_amount = 3000
matching_indices = [0, 2, 4]
sum_until_threshold(v) = 60
sum_until_threshold(range) = 45
combined_sum = 39

$ cargo test
running 5 tests
test tests::generic_iterator_functions_accept_different_iterator_types ... ok
test tests::iterator_adapters_are_lazy_until_consumed ... ok
test tests::matching_indices_finds_equal_positions_with_shorter_length ... ok
test tests::take_while_short_circuits_and_does_not_process_remaining_elements ... ok
test tests::total_valid_amount_sums_only_valid_transactions ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

🪜 Step-by-Step 解説

📋 コピーlet iter = data.iter().map(|x| { counter.set(counter.get() + 1); x * 2 });
assert_eq!(counter.get(), 0); // まだ実行されていない
let result: Vec<i32> = iter.collect();
assert_eq!(counter.get(), 5); // collect() が next() を5回呼んだ

📋 コピーfn sum_until_threshold(iter: impl Iterator<Item = i64>, threshold: i64) -> i64 {
    iter.take_while(|&x| x < threshold).sum()
}

💡 設計思想・なぜこう書くのか

🛑 コンパイルエラーが出た場合

filterのクロージャで参照の階層を誤ると、次のような型不一致エラーが出ることがあります。

読み方: filterは&Self::Itemを引数に取ります。.iter()のItemは既に&Transactionなので、filterのクロージャ引数は&&Transaction（参照の参照）になります。明示的に型注釈を書くとこの二重参照が露呈しますが、型推論に任せて|t| t.is_validと書けば、コンパイラが自動的に正しい階層を推論してくれるため実務ではほぼ問題になりません。型注釈を書きたい場合は|t: &&Transaction|と書く必要があります。

🌐 他言語との比較

JavaScriptの配列メソッドが「各段階で新しい配列を作る」のは、Rustのイテレータアダプタと最も対照的な点です。arr.map(f).filter(g)は、mapの結果として中間配列がまるごと1つヒープに確保され、その配列に対して改めてfilterが走ります。要素数が多いパイプラインほど、Rustとの実行効率の差が開いていきます。JavaのStream APIはRustと同じ遅延評価の設計思想を持ちますが、値のボクシング（プリミティブ型をオブジェクトとして扱うオーバーヘッド）が発生しやすい点でRustのゼロコスト抽象化とは異なります。

🏆 実務での使いどころ

• ETL/データ変換パイプライン: ログ行のパース→フィルタリング→集計、CSVレコードの検証→変換→DB挿入用構造体への詰め替えなど、複数段階のデータ変換をアダプタチェーンとして宣言的に書くのが実務での最頻出パターンです
• 大量データのメモリ効率的な走査: ファイルを1行ずつ読むBufRead::lines()とfilter/take_whileを組み合わせれば、ファイル全体をメモリに読み込まずにストリーミング処理できます。遅延評価が「必要な分だけ計算する」ことを型システムレベルで保証しています
• impl Iterator<Item = T>によるAPI設計: ライブラリの公開関数が「Vecを受け取る」のではなく「Iteratorを受け取る」ように設計すると、呼び出し側はVec・HashSet・Range・自作イテレータなど、あらゆるソースからそのままデータを渡せる柔軟なAPIになります

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: matching_indicesをwindows(2)（隣接ペアを走査するスライスメソッド）を使って書き換え、「連続する2要素の差が一定値以上になる箇所」を検出する関数に発展させてみてください
• 次回予告: Day 017ではカスタムイテレータの実装を扱います。自作の型に対してIteratorトレイトを自前実装し、next()をどう設計すればアダプタ群がタダで使えるようになるかを学びます

🎯 自己評価

自分の回答

気づき・メモ