"独占こそが秩序を生む。だが、時に我々は、秩序のために独占を手放すしかない。"

Rustの原則は、すべてのリソースに明確な“所有者”を定めることにある。
このルールによって、メモリ管理は構文的に保証され、破壊的なバグが生まれにくくなる。

しかし現実の設計では、「1つの値を複数の場所で共有したい」という要求が避けられない。
Rustはこの矛盾に対して、“制限付きでの妥協”という設計的解決を提示する。
それが Rc<T> と Arc<T> である。

この章では、所有権を共有するという選択が、どのように構文化されているか、
そしてなぜそれが「例外」ではなく「設計的に制御された逸脱」であるかを読み解いていく。

Rc：参照カウントによる“構造的妥協”

use std::rc::Rc;

let a = Rc::new(String::from("shared"));
let b = Rc::clone(&a);

このコードでは、a と b が同じデータを指している。
通常の String であれば、ムーブによって a は無効になるが、Rc は**参照カウント（Reference Counting）**を用いて複数の所有者を許容する。

重要なのは：

つまり、Rc は可変性を捨てることで共有を可能にした妥協の構文である。

可変にできない理由：破壊的同時性を防ぐ設計倫理

Rc<T> は基本的に 不変の値 を共有するための仕組みであり、同時に複数が書き換えることは許されない。

この制限は、安全性の保証と、実行時の複雑性を抑えるために存在する。

Rustは、“安全な状態を構文で維持しながら、必要な場合にだけ封印を解く”という設計哲学を貫いている。

use std::sync::Arc;

let a = Arc::new(String::from("shared across threads"));
let b = Arc::clone(&a);

Arc<T> は Rc<T> のスレッドセーフ版であり、atomicな参照カウントによってスレッド間の安全な共有を可能にしている。

つまり、「設計がスレッドをまたぐ」ことを構文で明示するために、Arc は存在している。

Rustは、スレッド境界を越えるという設計上の“重み”を、明確な型として設計に刻む。

Rc や Arc の使用にはランタイムコストが伴う：

これらは決して“悪”ではない。
むしろ、「本当に共有が必要なときだけ明示的に選べ」という構文的な設計制御である。

Rustでは、共有はデフォルトではない。
だが、どうしても必要なときには選べるようになっている。

このスタンスは、自由ではなく“慎重な選択肢”としての自由である。

共有は常に混乱を呼ぶ。
だからRustは、構文によってその混乱を制限し、“例外”を明示的に管理できるようにしている。

これは、自由と安全のバランスを構文で設計する試みに他ならない。

Rustにおける Rc や Arc は、安全で壊れにくい構造を維持しながら、必要最小限の共有を可能にする設計的手段である。

「すべてが共有される世界」では、所有は曖昧になる。
「すべてが単独所有でなければならない世界」では、表現力が失われる。
Rustは、その中間にある「構造的に制限された自由」を目指して、Rc と Arc を提供した。

"共有は、誤解を招く自由であってはならない。意図された構文として初めて、それは信頼となる。"