Day 048 — トレイトにSend + Syncを付けても、async fnが返すFutureまでSendにはならない。tokio::spawnの「future cannot be sent between threads safely」を2段階で直す

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

Day 046・047では「ネイティブのasync fn in traitはトレイトオブジェクト（dyn Trait）にはできない」という制約を確認しました。しかし実務でもっと頻繁に踏むのは、実は別の壁です。ジェネリクス経由で使っているのに、tokio::spawnに渡した瞬間だけ怒られるというパターンです。

tokio::spawnのシグネチャを思い出してください。

📋 コピーpub fn spawn(future: F) -> JoinHandle
where
    F: Future + Send + 'static,

マルチスレッドランタイム（#[tokio::main]のデフォルト）は、実行中のタスクをワーカースレッド間で自由に移動させます（work-stealing）。そのためタスクの中身であるFutureは、あるスレッドで生成されて別のスレッドでpollされる可能性があり、コンパイラはそれを型システムで保証させるためにSendを要求します。

ここで問題になるのが、「トレイト自身がSendであること」と「トレイトメソッドが返すFutureがSendであること」は、Rustの型システム上まったく別の主張であるという点です。トレイトにSend + Syncというスーパートレイト境界を付ければ「このトレイトを実装する型はSendだ」とは言えますが、async fnが返す匿名のFuture型については、そのトレイト境界は一切関与しません。この2つを混同すると、「スーパートレイトにSendを付けたのに、まだtokio::spawnが通らない」という、原因の切り分けが難しいバグにぶつかります。

📝 問題

以下のコードは、リポジトリの検索結果をバックグラウンドタスクで取得しようとしていますが、コンパイルが通りません。

📋 コピーuse std::collections::HashMap;

trait Repository {
    async fn find(&self, id: u64) -> Option;
}

struct InMemoryRepo {
    data: HashMap,
}

impl Repository for InMemoryRepo {
    async fn find(&self, id: u64) -> Option {
        self.data.get(&id).cloned()
    }
}

fn spawn_lookup(repo: R, id: u64) {
    tokio::spawn(async move {
        let result = repo.find(id).await;
        println!("{:?}", result);
    });
}

#[tokio::main]
async fn main() {
    let mut data = HashMap::new();
    data.insert(1, "alice".to_string());
    let repo = InMemoryRepo { data };
    spawn_lookup(repo, 1);
}

1. まずcargo buildでどんなエラーが出るか予想し、実際にコンパイルしてエラーメッセージを確認してください（2種類のエラーが同時に出ます）
2. 1つ目のエラー（R型自体がSendでない）を、RepositoryトレイトにSend + Syncのスーパートレイト境界を追加することで直してください
3. スーパートレイト境界を追加しただけでは2つ目のエラー（findが返すFutureがSendでない）が消えないことを確認し、そのエラーメッセージを読んでください
4. findメソッドの宣言を、async fn糖衣構文をやめてfn find(&self, id: u64) -> impl Future<Output = Option<String>> + Sendという展開後の形に書き換えることで完全に直してください（impl側はasync fnのままでよいことも確認してください）
5. 修正後、spawn_lookupがJoinHandleを返すように変更し、mainと#[tokio::test]の両方で検索結果を検証するテストを書いてください（見つかる場合・見つからない場合の両方）

🔍 ヒント（段階的開示）

📋 コピーuse std::future::Future;

trait Repository: Send + Sync {
    fn find(&self, id: u64) -> impl Future
> + Send;
}

impl Repository for InMemoryRepo {
    // impl側はasync fnの糖衣構文のままでよい。
    // トレイト側の宣言に + Send が付いているおかげで、
    // ここで生成される匿名Futureにも + Send が要求される。
    async fn find(&self, id: u64) -> Option {
        self.data.get(&id).cloned()
    }
}

✅ 模範解答

📋 コピー// Cargo.toml に以下が必要:
// [dependencies]
// tokio = { version = "1", features = ["full"] }

use std::collections::HashMap;
use std::future::Future;

/// `Send + Sync` をスーパートレイトとして要求することで、
/// 「`Repository` を実装する型 `R` 自体」がスレッド間で送受信
/// 可能であることを保証する。ただしこれだけでは、
/// `find` が返す匿名の Future 型が Send であることまでは
/// 保証されない（このあとの `impl Future<...> + Send` が別途必要）。
trait Repository: Send + Sync {
    /// `async fn find(...)` という糖衣構文では戻り値の匿名Futureに
    /// 追加の境界を書けないため、あえて展開後の形で書いて
    /// `+ Send` を明示する。
    fn find(&self, id: u64) -> impl Future
> + Send;
}

struct InMemoryRepo {
    data: HashMap,
}

impl Repository for InMemoryRepo {
    // impl側は通常どおり async fn 糖衣構文で書ける。
    // トレイト側の宣言に + Send が付いているおかげで、
    // ここで生成される匿名Futureにも + Send の制約がかかる。
    async fn find(&self, id: u64) -> Option {
        self.data.get(&id).cloned()
    }
}

/// ジェネリクス `R: Repository + 'static` は、`Repository: Send + Sync`
/// というスーパートレイト境界のおかげで自動的に `R: Send` も満たす。
/// 加えて `find` の戻り値が `+ Send` を明示しているため、
/// `tokio::spawn` の `F: Future + Send + 'static` を満たせる。
fn spawn_lookup(
    repo: R,
    id: u64,
) -> tokio::task::JoinHandle> {
    tokio::spawn(async move { repo.find(id).await })
}

#[tokio::main]
async fn main() {
    let mut data = HashMap::new();
    data.insert(1, "alice".to_string());
    let repo = InMemoryRepo { data };

    let handle = spawn_lookup(repo, 1);
    let result = handle.await.unwrap();
    println!("{:?}", result);
}

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

    #[tokio::test]
    async fn spawn_lookup_returns_found_value_from_another_task() {
        let mut data = HashMap::new();
        data.insert(1, "alice".to_string());
        let repo = InMemoryRepo { data };

        let result = spawn_lookup(repo, 1).await.unwrap();
        assert_eq!(result, Some("alice".to_string()));
    }

    #[tokio::test]
    async fn spawn_lookup_returns_none_for_missing_id() {
        let repo = InMemoryRepo { data: HashMap::new() };

        let result = spawn_lookup(repo, 999).await.unwrap();
        assert_eq!(result, None);
    }
}

🪜 Step-by-Step 解説

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

RustのSend/Syncは「マーカートレイト」であり、コンパイラは型の構造（フィールドの型・キャプチャする変数の型）を再帰的に見て自動的に実装の有無を判定します（auto trait）。これは通常の型には強力に働きますが、async fnが返す「匿名のFuture型」は少し事情が違います。この匿名型の中身（ステートマシンとしてどんなフィールドを持つか）はimplブロックごとに実装依存で決まるため、トレイト定義の時点では「その匿名型がSendかどうか」を確定させられません。だからこそRustは、トレイト定義者に対して「この匿名Future型にはSendを要求する」という意思表示を、impl Future<...> + Sendという形で明示的に書かせる設計にしています。もし黙って自動判定に任せてしまうと、ある実装だけが内部でRc<T>のような非Send型を使ったせいで、トレイトを跨いだ抽象化全体がSendになったりならなかったりする、という予測不能な状態が生まれてしまいます。「境界は明示的に宣言し、実装側にそれを守らせる」というのは、Rustの型システム全体を貫く一貫した思想です。

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

問題のコード（スーパートレイトなし・RPITIT展開なし）をそのままビルドすると、次の2つのエラーが同時に出ます。

🌐 他言語との比較

GoやJavaでは「このFutureや戻り値は他のスレッド・ゴルーチンに安全に渡せるか」という性質は、型システムの外側（コメント・命名規則・レビュー）でしか表現できません。RustはこれをSendという型システム上の制約として扱い、満たさない限りそもそもコンパイルが通らないという形で、実行時まで問題が持ち越されることを防ぎます。今回のような「一見動きそうなのにコンパイルが通らない」という体験は、他言語出身のエンジニアには煩わしく感じられがちですが、裏を返せば「本番でしか再現しないデータ競合」を設計段階で潰しているという恩恵でもあります。

🏆 実務での使いどころ

• Webサーバーのリクエストハンドラ: axumやactix-webのハンドラは基本的にマルチスレッドランタイム上で動くため、ハンドラ内から呼び出すリポジトリ層・外部APIクライアント層のトレイトは、今回のようにSend + Sync境界と+ Sendな戻り値を意識して設計する必要がある
• バックグラウンドジョブキュー: ジョブをどのワーカースレッドが処理するか事前に決まっていないシステムでは、ジョブが内部で呼ぶトレイトメソッドの戻り値がSendでないと、そもそもキューに積めない（tokio::spawnできない）
• トレイトを外部クレートとして公開する場合: 自分のクレートの利用者がマルチスレッドランタイムで使うことを想定するなら、トレイト定義時点でSend + SyncとFutureの+ Sendを意識して設計しておかないと、利用者側がtokio::spawnしようとした瞬間に原因のわかりにくいエラーに直面する
• 段階的な導入判断: シングルスレッドランタイム（#[tokio::main(flavor = "current_thread")]）だけで完結するアプリケーションなら、Send境界はそもそも不要になる場合もある。マルチスレッドランタイムを使うかどうかを先に決めてから、トレイト設計にSend境界を織り込むかを判断する

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: tokio::task::spawn_localとcurrent_threadランタイムの組み合わせを試し、同じRepositoryトレイトからSend境界を外した場合にどこまでコンパイルが通るか（そしてマルチスレッドランタイムに戻すとどこで壊れるか）を確認する
• 次回予告: unsafe Rustの基礎（生ポインタ操作） — 5つのunsafe操作と、コンパイラが保証してくれなくなる境界線がどこかを学ぶ

🎯 自己評価

自分の回答

気づき・メモ