入出力プロジェクトを改善する

このイテレータに関する新しい知識があれば、イテレータを使用してコードのいろんな場所をより明確で簡潔にすることで、第12章の入出力プロジェクトを改善することができます。イテレータがConfig::new関数とsearch関数の実装を改善する方法に目を向けましょう。

イテレータを使用して`clone`を取り除く

リスト12-6において、スライスに添え字アクセスして値をクローンすることで、Config構造体に値を所有させながら、 String値のスライスを取り、Config構造体のインスタンスを作るコードを追記しました。リスト13-24では、リスト12-23のようなConfig::newの実装を再現しました:

ファイル名: src/lib.rs

impl Config {
    pub fn new(args: &[String]) -> Result<Config, &'static str> {
        if args.len() < 3 {
            return Err("not enough arguments");
        }

        let query = args[1].clone();
        let filename = args[2].clone();

        let case_sensitive = env::var("CASE_INSENSITIVE").is_err();

        Ok(Config { query, filename, case_sensitive })
    }
}

リスト13-24: リスト12-23からConfig::new関数の再現

その際、将来的に除去する予定なので、非効率的なclone呼び出しを憂慮するなと述べました。えっと、その時は今です！

引数argsにString要素のスライスがあるためにここでcloneが必要だったのですが、 new関数はargsを所有していません。Configインスタンスの所有権を返すためには、 Configインスタンスがその値を所有できるように、Configのqueryとfilenameフィールドから値をクローンしなければなりませんでした。

イテレータについての新しい知識があれば、new関数をスライスを借用する代わりに、引数としてイテレータの所有権を奪うように変更することができます。スライスの長さを確認し、特定の場所に添え字アクセスするコードの代わりにイテレータの機能を使います。これにより、イテレータは値にアクセスするので、Config::new関数がすることが明確化します。

ひとたび、Config::newがイテレータの所有権を奪い、借用する添え字アクセス処理をやめたら、 cloneを呼び出して新しくメモリ確保するのではなく、イテレータからのString値をConfigにムーブできます。

返却されるイテレータを直接使う

入出力プロジェクトのsrc/main.rsファイルを開いてください。こんな見た目のはずです:

ファイル名: src/main.rs

fn main() {
    let args: Vec<String> = env::args().collect();

    let config = Config::new(&args).unwrap_or_else(|err| {
        eprintln!("Problem parsing arguments: {}", err);
        process::exit(1);
    });

    // --snip--
}

リスト12-24のようなmain関数の冒頭をリスト13-25のコードに変更します。これは、Config::newも更新するまでコンパイルできません。

ファイル名: src/main.rs

fn main() {
    let config = Config::new(env::args()).unwrap_or_else(|err| {
        eprintln!("Problem parsing arguments: {}", err);
        process::exit(1);
    });

    // --snip--
}

リスト13-25: env::argsの戻り値をConfig::newに渡す

env::args関数は、イテレータを返します！イテレータの値をベクタに集結させ、それからスライスをConfig::newに渡すのではなく、今ではenv::argsから返ってくるイテレータの所有権を直接Config::newに渡しています。

次に、Config::newの定義を更新する必要があります。入出力プロジェクトのsrc/lib.rsファイルで、 Config::newのシグニチャをリスト13-26のように変えましょう。関数本体を更新する必要があるので、それでもコンパイルはできません。

ファイル名: src/lib.rs

impl Config {
    pub fn new(mut args: std::env::Args) -> Result<Config, &'static str> {
        // --snip--

リスト13-26: Config::newのシグニチャをイテレータを期待するように更新する

env::args関数の標準ライブラリドキュメントは、自身が返すイテレータの型は、std::env::Argsであると表示しています。 Config::new関数のシグニチャを更新したので、引数argsの型は、&[String]ではなく、 std::env::Argsになりました。argsの所有権を奪い、繰り返しを行うことでargsを可変化する予定なので、 args引数の仕様にmutキーワードを追記でき、可変にします。

添え字の代わりに`Iterator`トレイトのメソッドを使用する

次に、Config::newの本体を修正しましょう。標準ライブラリのドキュメントは、 std::env::ArgsがIteratorトレイトを実装していることにも言及しているので、それに対してnextメソッドを呼び出せることがわかります！リスト13-27は、リスト12-23のコードをnextメソッドを使用するように更新したものです:

ファイル名: src/lib.rs

fn main() {}
use std::env;

struct Config {
    query: String,
    filename: String,
    case_sensitive: bool,
}

impl Config {
    pub fn new(mut args: std::env::Args) -> Result<Config, &'static str> {
        args.next();

        let query = match args.next() {
            Some(arg) => arg,
            // クエリ文字列を取得しませんでした
            None => return Err("Didn't get a query string"),
        };

        let filename = match args.next() {
            Some(arg) => arg,
            // ファイル名を取得しませんでした
            None => return Err("Didn't get a file name"),
        };

        let case_sensitive = env::var("CASE_INSENSITIVE").is_err();

        Ok(Config { query, filename, case_sensitive })
    }
}

リスト13-27: Config::newの本体をイテレータメソッドを使うように変更する

env::argsの戻り値の1番目の値は、プログラム名であることを思い出してください。それは無視し、次の値を取得したいので、まずnextを呼び出し、戻り値に対して何もしません。2番目に、 nextを呼び出してConfigのqueryフィールドに置きたい値を得ます。nextがSomeを返したら、 matchを使用してその値を抜き出します。Noneを返したら、十分な引数が与えられなかったということなので、 Err値で早期リターンします。filename値に対しても同じことをします。

イテレータアダプタでコードをより明確にする

入出力プロジェクトのsearch関数でも、イテレータを活用することができます。その関数はリスト12-19に示していますが、以下のリスト13-28に再掲します。

ファイル名: src/lib.rs

pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> {
    let mut results = Vec::new();

    for line in contents.lines() {
        if line.contains(query) {
            results.push(line);
        }
    }

    results
}

リスト13-28: リスト12-19のsearch関数の実装

イテレータアダプタメソッドを使用して、このコードをもっと簡潔に書くことができます。そうすれば、可変な中間のresultsベクタをなくすこともできます。関数型プログラミングスタイルは、可変な状態の量を最小化することを好み、コードを明瞭化します。可変な状態を除去すると、検索を同時並行に行うという将来的な改善をするのが、可能になる可能性があります。なぜなら、resultsベクタへの同時アクセスを管理する必要がなくなるからです。リスト13-29は、この変更を示しています:

ファイル名: src/lib.rs

pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> {
    contents.lines()
        .filter(|line| line.contains(query))
        .collect()
}

リスト13-29: search関数の実装でイテレータアダプタのメソッドを使用する

search関数の目的は、queryを含むcontentsの行全てを返すことであることを思い出してください。リスト13-19のfilter例に酷似して、このコードはfilterアダプタを使用してline.contains(query)が真を返す行だけを残すことができます。それから、合致した行を別のベクタにcollectで集結させます。ずっと単純です！ご自由に、同じ変更を行い、search_case_insensitive関数でもイテレータメソッドを使うようにしてください。

次の論理的な疑問は、自身のコードでどちらのスタイルを選ぶかと理由です: リスト13-28の元の実装とリスト13-29のイテレータを使用するバージョンです。多くのRustプログラマは、イテレータスタイルを好みます。とっかかりが少し困難ですが、いろんなイテレータアダプタとそれがすることの感覚を一度掴めれば、イテレータの方が理解しやすいこともあります。いろんなループを少しずつもてあそんだり、新しいベクタを構築する代わりに、コードは、ループの高難度の目的に集中できるのです。これは、ありふれたコードの一部を抽象化するので、イテレータの各要素が通過しなければならないふるい条件など、このコードに独特の概念を理解しやすくなります。

ですが、本当に2つの実装は等価なのでしょうか？直観的な仮説は、より低レベルのループの方がより高速ということかもしれません。パフォーマンスに触れましょう。

The Rust Programming Language 日本語版