【Rust】ジェネリックな構造体とメソッドの部分特殊化を参照の場合でも使えるようオーバーロードしたい

Question

こんにちは。Rustでソフトウェア開発をしています。

C++でいうテンプレート部分特殊化をRustのコードで実現したいです。

いろんなWebサイトを調べてみました。

• ジェネリクスとトレイトの組み合わせでconflictが発生する場合の回避策
• Rust でメソッドのオーバーロード

しかし問題は解決できません。

forの後の部分(structなど)の部分特殊化についてはいくつか見かけました。ですがforの前部分(trait)の部分特殊化について書かれているところを見つけられませんでした。

問題のコード

use std::sync::{Arc, Mutex};

pub trait TryLockAndThen<T, U>
where
    T: ?Sized,
{
    type Output;
    fn run<F>(&self, f: F) -> Self::Output
    where
        F: FnOnce(&mut T) -> Self::Output;
}

impl<T, U> TryLockAndThen<T, U> for Arc<Mutex<T>>
where
    T: ?Sized,
    U: Default,
{
    type Output = U;
    fn run<F>(&self, f: F) -> Self::Output
    where
        F: FnOnce(&mut T) -> Self::Output,
    {
        match self.try_lock().as_deref_mut() {
            Err(_) => {
                let default = U::default();
                return default;
            }
            Ok(target) => return f(target),
        }
    }
}
impl<'a, T, U> TryLockAndThen<T, &'a U> for Arc<Mutex<T>>
where
    T: ?Sized,
    U: Default,
{
    type Output = &'a U;
    fn run<F>(&self, f: F) -> Self::Output
    where
        F: FnOnce(&mut T) -> Self::Output,
    {
        match self.try_lock().as_deref_mut() {
            Err(_) => {
                let default = U::default();
                return &default;
            }
            Ok(target) => return f(target),
        }
    }
}

エラーメッセージ

error[E0119]: conflicting implementations of trait `helper::TryLockAndThen<_, &_>` for type `std::sync::Arc<std::sync::Mutex<_>>`
  --> interactors/src/helper.rs:32:1
   |
13 | / impl<T, U> TryLockAndThen<T, U> for Arc<Mutex<T>>
14 | | where
15 | |     T: ?Sized,
16 | |     U: Default,
...  |
30 | |     }
31 | | }
   | |_- first implementation here
32 | / impl<'a, T, U> TryLockAndThen<T, &'a U> for Arc<Mutex<T>>
33 | | where
34 | |     T: ?Sized,
35 | |     U: Default,
...  |
49 | |     }
50 | | }
   | |_^ conflicting implementation for `std::sync::Arc<std::sync::Mutex<_>>`

runメソッドの戻り値を、U型と＆U型の両パターンに同じシグネチャで実現したいだけなのですが…

ご存じの方いらっしゃいましたら恐縮ですが、ご教示いただけますと幸いです。

よろしくお願いいたします。

Answer 1

こんにちは。多少調べてみましたができないようです。
エラーの理由は U に参照型が含まれているので新たに &U を定義すると参照に対する定義が重複してしまうというものです。特に参照に限定して実装したい場合は specializationというものがありますが、長らく議論中のままです。すぐに使えるものではないでしょう。

なお、もし定義重複を回避できたとしても &U の方の定義はローカル変数のポインタを返しているのでコンパイルするとエラーになります。

error[E0515]: cannot return reference to local variable `default`
  --> teratail_template.rs:50:24
   |
50 |                 return &default;
   |                        ^^^^^^^^ returns a reference to data owned by the current function

error: aborting due to previous error; 1 warning emitted

For more information about this error, try `rustc --explain E0515`. 

質問とは関係ありませんが TryLockAndThen の Output は特になくてもよさそうです。型パラメータから従属して決まっている訳ではないので Self::Output を使っている箇所は全て U で置き換えられるように見えます。

Comments

[akira_kano1101]

blackendgold様

ご回答ありがとうございます。

やはりできませんか、そうですよね。私も`TryLockAndThen`構造体に`U`を指定していたのを`run`メソッドに変えて試してみましたが上手くいきませんでした。

参照に対応させるのは諦めることにしました。しかしまだ話には続きがありまして…

そもそもモチベーションですが、なぜ`U`を参照にも対応させるようにしようと考えたのかというと、与える`F`内部の処理で戻り値としてとてもサイズの大きい`Vec`を取り出したい（`U`に`&Vec`が入るようにしたかった）からなんです。しかしそれを諦めて`clone()`やコピートレイトを使ってしまうとパフォーマンスが問題になると思ったのでそれを解決したい、ということだったからなんです。

他の方法として、これは試しているところなのですが、Boxを使えば解決できそうな気がしています。ただ私の知識がまだ浅く言語仕様を分かっていないのですが、`U`を`Box::new`でヒープオブジェクトにして戻り値を返すとパフォーマンスには問題ありますか？

もしくはそれ以外に良い代替案などもなさそうでしょうか。

お時間よろしければご回答よろしくお願いします。

[blackenedgold]

そうであればそのまま `Vec<T>` を返して問題ありません。 `Vec<T>` は要素列へのポインタとバッファ長と要素数だけからなる軽いデータ型なのでそのままムーブさせるのはコストはかかりません。 `clone` などを使うとバッファまでコピーします。
試しに巨大なデータを格納する `Vec<T>` のサイズを測っても24と出ます。
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ded80ca5fad50adb6644a071b407cc7c

`Box` を使ったときのパフォーマンスについては測らないとなんとも言えないですね。 `Box::new` で一度ヒープにデータを確保するコストがかかりますが、それ以降はムーブにかかるコストが減り、ポインタを介するのでデータアクセスにかかるコストが増えます。コストが減る部分と増える部分があるので実際にベンチマークをとらないと分からないと思います。

[akira_kano1101]

そのまま`Vec<T>`を返すとムーブになるんですね。値がコピーされると思っていました。
メモリサイズの測り方も教えてもらえて、面白いです。
丁寧なご説明のおかげでムーブやBoxについての知識が増えました。
非常に助かりました。開発に活かしたいと思います。ありがとうございます。