回答。

問題の背景

Rustでは、型が他の値（例えば、BoxやRc）をカプセル化することが多く、開発者はC++のポインタのようにネストされた値に透明にアクセスしたいと考えました。Derefトレイト（およびDerefMut）が追加され、メソッドや演算子を介して便利にアクセスするための自動逆参照ロジックが導入されました。

問題点

ポインタやスマートポインタがいつどのように自動的に展開されるかについての混乱は、コンパイルエラーやメソッドの予期しない動作を引き起こし、時には余分なコピーや借用のせいで非最適なコードを生じることがあります。

解決策

Derefトレイトは自分の逆参照ルールを定義することを可能にします（例えば、Box<T>はDerefを実装することでTのように振る舞います）。自動逆参照のシステムは、メソッドや演算子にアクセスするときにDeref型への参照を「展開」しようとします。これにより、以下のように記述できます：

use std::rc::Rc;

fn print_len(s: &str) {
    println!("{}", s.len());
}

let s: Rc<String> = Rc::new("hello".into());
print_len(&s); // auto-deref: &Rc<String> -> &String -> &str

主な特徴：

自動逆参照は、メソッド呼び出しや演算子*、および参照型のパターンマッチング時に機能します。
Box、Rc、Arcは「透明な」アクセスのためにDeref（およびしばしばDerefMut）を実装します。
デレフ coercion は一方向の変換にのみ機能します。

トリッキーな質問。

デレフは開発者が「期待する」時に常に自動で行われますか？

いいえ：デレフコーションは、メソッド呼び出し時またはDeref Targetを通じてシグネチャで指定された別の型への参照が必要な場合にのみ発生します。これはすべての式では機能しません。例えば、パターンマッチングでは機能しません。

デレフコーションは借用や所有のルールを破る可能性がありますか？

いいえ。デレフコーションは借用のルールを完全に遵守します。Derefを介して二つのmutable参照を得ることは不可能であり、Rustの所有権の安全性を損なうことはありません。

&Tから&Uへの自動逆参照は可能ですか？T: Deref<Target=U>であり、両方の型が明示的に関連付けられていない場合は？

はい、&Uを期待する関数を呼び出す場合、&Tを渡すと、TがDeref<Target=U>を実装していると自動的に変換されます。

コード例：

struct Wrapper(String);

impl std::ops::Deref for Wrapper {
    type Target = String;
    fn deref(&self) -> &Self::Target {
        &self.0
    }
}

fn takes_str(s: &str) {}
let w = Wrapper("mytext".into());
takes_str(&w); // auto-deref: &Wrapper -> &String -> &str

よくある間違いやアンチパターン

&Tを期待するメソッドを記述し、Tを渡し、借用を忘れる。
適用されない場所での自動逆参照を期待する（例えば、デストラクチャリング時）。
独自のスマートポインタ構造体を作成する際にDeref/DerefMutを実装しない。

実生活の例

ネガティブケース

開発者が独自のスマートポインタを実装しましたが、Derefの実装を追加せず、自分の型が通常の値として振る舞うことを期待しました。

利点：

型がコンパイルされ、ネストされた値に明示的にアクセスできる。

欠点：

メソッド呼び出し時に自動逆参照が機能せず、標準ライブラリやサードパーティのライブラリを使用する際の不便さが生じます。

ポジティブケース

独自のラッパー型がDerefおよびDerefMutをBoxと同様に実装しており、すべての標準関数とのシームレスな統合が可能です。