メモリ：5 つの戦略、1 つの選択

暗黙を明示にしたい言語にとって、メモリは最初の本当の試金石だ。それは古典的な隠れた コスト：値がどこに住み、誰が所有し、いつ解放されるか —— 多くの言語はそのどれも考え なくてよいことにして、その便利さの代償を、ポーズ・リーク・解放後使用で払う。Mere は メモリを、まさに自分の思想が「表に出せ」と言う類のものとして扱う。

設計空間

メモリを管理する方法には事欠かない。そしてそれぞれが「これを誰が、いつ解放するか？」 への異なる答えだ。

• ガベージコレクション —— ランタイムが決める。書くのは簡単だが、確保と所有権が 見えなくなり、「いつ」はあなたの制御下にない。
• 手動 —— あなたが明示的に決める。完全な制御、安全性なし。
• 所有と借用 —— 単一の所有者、参照で借用、所有者がスコープを抜けたら解放。安全で 精密だが、儀式の代償を伴う。とくに共有の多いグラフ状データで。
• アリーナ / リージョン —— 多くのものを一つの領域に確保し、領域ごと一括で解放 する。寿命を共有するオブジェクトの束 —— AST、リクエスト、フレーム —— に最適で、 寿命が揃わないときは最悪。

どれも全所に勝てはしない。所有権は、明確な単一所有者を持つ値には美しく、相互参照する ノードの網には苦しい。アリーナはその網には完璧で、束を越えて生き延びる長寿命の値には 無用だ。GC はそのすべてを塗り隠し、そうすることで、Mere が見えるようにしたいまさに その当のものを隠す。

Mere の答え：選ぶ、そして選択を明示する

どの単一戦略も全所で正しくはないので、Mere はあなたのために一つを選ばない。小さな 集合を提供し、プログラマにデータごとに選ぶことを求める。選択は型に載る。最初の 設計空間は 5 つの戦略だった：

1. owned —— 単一の所有者。移動すると古い束縛は無効になる（Rust のように）。明確な 住処が一つある値のために。
2. borrowed —— 所有権を取らずに参照でアクセスする。共有形か可変形で。データを 手放さずに渡すために。
3. arena —— 名前付きアリーナに確保する。その中のすべてが一括で解放される。グラフ 状データに理想的で、一つのアリーナ内の相互参照は自由だ。
4. region —— ブロックに寿命が紐づくスコープ付きの領域。
5. stack —— ありふれた、自動のケース。

大事なのはリストではない。戦略が沈黙しないことだ。アリーナに住む値はそれを型に 言う。借用参照は、それが借りている当のものとは別の型だ。所有権を文脈から推し量ったり 慣習を信じたりはしない —— 読む。これは言語の他の至る所と同じ賭けを、プログラムが最も よく間違える資源に適用したものだ。

妥協を、名指しで

第 1 回で、Mere はトレードオフを無いふりせず名指しすると約束した。今章のそれを率直に： メモリ戦略を選ぶのは、GC に決めさせるより手間だ。 寿命を考えねばならず、型システムが それを守らせ、GC なら些事のパターンのいくつかは自分で設計するものになる。Mere はその コストをあえて受け入れる。なぜなら、それが買うもの —— プログラムを読んでメモリの行方が 分かること、あなたに代わって静かに決めるランタイムが無いこと —— こそが、最適化して いる当のものだからだ。そして所有権注釈が要する冗長さは、第 1 回の通り、ここでは安い 資源だ。

この先

5 つの戦略は、設計が 始まった 場所であって、着地した場所ではない。並べてみると、 すぐに、後の章が答える問いが立った：

• arena と region は疑わしいほど似ている —— 本当に両方要るのか？（次回は、それらを 一つに畳む話だ。）
• そもそも誰がアリーナに入れるのか？ すべてではない：OS リソースを持つ値は、 ポインタをリセットするだけでは解放できない。その制約 —— Trivial と呼ぶ —— と、 片付けが 本当に 必要な値のための別の機構（Drop、with で走る）は、数回先だ。
• 「リージョンへのビュー」とは正確に何を意味するのか？ それは独立した小さな理論に なる。

だから今回は地図であって、土地ではない。土地 —— そこに何が住めて、どう片付けられるかの 明確な規則を持つ、統一されたリージョンモデル —— を、Part II の残りが築く。次回：なぜ arena と region が一つになったか。