Rust's Block Pattern

以下は、あまり語られないようなイディオムですが、Rust コードをよりクリーンで頑丈にする効果があると感じています。
実際にこのパターンに名前が付いているかどうかは分かりませんので、「ブロック・パターン」という名称で呼んでいます。頻繁に利用しており、他の Rust プロジェクトでも採用すればコードが整然とすると思います。
もし既存の名前がある場合は教えてください。

---

ブロック・パターンとは？

Rust のブロック

{ … }

は有効な式です。そのため、ブロックを評価した結果を変数に代入できます。

let foo = {
    let x = 1;
    let y = 2;
    x + y          // ← ブロックの最後の式が返り値になる
};

上記は

let foo = 3;

と同等です。

---

なぜ重要なのか？

たとえば、設定ファイルを読み込み、その内容に応じて複数の HTTP リクエストを送る関数があるとします。
設定をロードするには以下の手順が必要です。

1. ファイルから生データ（バイト列）を読む
2. コメントを除去（例：コメント付き JSON）
3. 生成した文字列を JSON としてパース

単純に実装すると次のようになります。

use regex::{Regex, RegexBuilder};
use std::{fs, sync::LazyLock};

#[derive(serde::Deserialize)]
struct Config { /* ... */ }

static STRIP_COMMENTS: LazyLock<Regex> = LazyLock::new(|| {
    RegexBuilder::new(r"//.*")
        .multi_line(true)
        .build()
        .expect("regex build failed")
});

fn foo(cfg_file: &str) -> anyhow::Result<()> {
    let config_data = fs::read(cfg_file)?;
    let config_string = String::from_utf8(&config_data)?;
    let stripped_data = STRIP_COMMENTS.replace(&config_string, "");
    let config = serde_json::from_str(&stripped_data)?;

    send_http_request(&config.url1)?;
    send_http_request(&config.url2)?;
    send_http_request(&config.url3)?;

    Ok(())
}

このコードは動作しますが、いくつか欠点があります。

• 名前空間の汚染 –

  config_data

  ・

  config_string

  ・

  stripped_data

  ・

  config

  という四つの一時変数が関数内に残る。
  解析後は

  config

  のみが必要です。
• 意図が隠れている – 読む側は何行も読むまで「最終的に Config を作り出す」という目的を理解できません。
• 誤用のリスク – 一時変数は可変 (

  mut

  ) であるため、後から偶然変更される恐れがあります。

---

ブロックでロジックをカプセル化

ブロック・パターンでは、すべての中間ステップを一つの式内に収めることで上記問題を解決します。

fn foo(cfg_file: &str) -> anyhow::Result<()> {
    let config = {
        // コメント除去用正規表現（キャッシュ済み）
        static STRIP_COMMENTS: LazyLock<Regex> = LazyLock::new(|| {
            RegexBuilder::new(r"//.*")
                .multi_line(true)
                .build()
                .expect("regex build failed")
        });

        let raw_data = fs::read(cfg_file)?;
        let data_string = String::from_utf8(&raw_data)?;
        let stripped_data = STRIP_COMMENTS.replace(&data_string, "");
        serde_json::from_str(&stripped_data)?
    };

    send_http_request(&config.url1)?;
    send_http_request(&config.url2)?;
    send_http_request(&config.url3)?;

    Ok(())
}

メリット

1. 意図が明確 –

   let config = { … }

   という代入文だけで「ここは設定オブジェクトを生成するためのブロックだ」と即座にわかります。
2. 名前空間の衛生性 –

   raw_data

   ・

   data_string

   など中間変数はブロック内に限定され、関数の他の部分からはアクセスできません。
3. 自動クリーンアップ – ブロックが終わるとそのスコープ内の値はすべてドロップし、リソースが解放されます。

---

別案：別関数へ抽出

同じ効果を得るには、上記ロジックを独立したヘルパー関数に切り出す方法もあります。
しかしその場合、次の欠点があります。

1. コードフローが線形でなくなるため、読者は別ファイルや別場所へジャンプしなければならない。
2. 中間値を他で使う必要がある場合は、すべてパラメータとして渡さねばならない。

ブロック・パターンは、インラインの可読性を保ちつつ一時変数を隔離できる点で優れています。

---

可変性の削減

さらに微妙なメリットとして、ブロックは可変性を限定できます。

let data = {
    let mut temp = vec![];
    temp.push(1);
    temp.extend_from_slice(&[4, 5, 6, 7]);
    temp   // ブロックの戻り値は不変になる
};

data.iter().for_each(|x| println!("{x}"));
return data[2];

ブロック内では

temp

が可変ですが、外側に出ると不変な

Vec<i32>

になります。
これにより初期化フェーズ以降の意図しない変更を防げます。

---

終わりに

このパターンが Rust コミュニティで既に名前付けされているかは不明ですが、共有する価値はあると考えています。
関数を簡潔に保ち、意図を明示し、予期せぬ副作用から守るための手段として、ぜひ採用してみてください。