戻るところで、残っているものを除去します。されるとき、ヒープの最後の残りも除去されます。他の言語では何をしているのか?ガベージコレクタを備えた多くの言語はデフォルトでヒープアロケートします。すべての値がボックス化されています。なっている理由がいくつかあるのですが、それはこのチュートリアルの範囲外です。そのことが100%真であると言えなくなるような最適化もいくつか行われることがあります。頼りにするかわりに、ガベージコレクタがヒープを取り扱います。後入れ先出し)」セマンティクスをとるしかないということだからです。ヒープアロケーションは厳密により普遍的で、ストレージを任意の順番でプールから取得したり、プールに返却することが許されているのですが、よりコストがかさみます。一般的にはスタックアロケーションを選ぶべきで、そのためRustはデフォルトでスタックアロケートします。スタックのLIFOモデルはより単純で、基本的なレベルに置かれています。このことは、実行時の効率性と意味論に大きな影響を与えています。機械は「スタックポインタ」と呼ばれる単一の値を増減します。ヒープアロケートされたメモリは任意の時点で解放され、またヒープアロケートされたそれぞれのブロックは任意のサイズになりうるので、一般的にメモリマネージャは再利用するメモリを特定するためにより多くの仕事をします。この事柄についてより詳しいことを知りたいのであれば、こちらの論文がよいイントロダクションになっています。意味論への影響スタックアロケーションはRustの言語自体へ影響を与えており、したがって開発者のメンタルモデルにも影響しています。Rust言語がどのように自動メモリ管理を取り扱うかは、LIFOセマンティクスに従っています。ヒープアロケートされユニークに所有されたボックスのデアロケーションさえも、スタックベースのLIFOセマンティクスに従っていることは、この章を通して論じてきたとおりです。非LIFOセマンティクスの柔軟性(すなわち表現能力)は一般的に、いつメモリが解放されるべきなのかをコンパイラがコンパイル時に自動的に推論できなくなることを意味するので、デアロケーションを制御するために、ときに言語自体の外部に由来するかもしれない、動的なプロトコルに頼らなければなりません。使っている参照カウントはその一例です。)突き詰めれば、ヒープアロケーションによって増大した表現能力は(例えばガベージコレクタという形の)著しい実行時サポートか、(Rustコンパイラが提供していないような検証を必要とする明示的なメモリ管理呼び出しという形の)著しいプログラマの努力のいずれかのコストを引き起こすのです。指すと決めることで、この問題を解決しています。このような用語法を使う人はとても少なく、文脈で両者を区別しています。ここでは、その慣習に則っています。↩(「変数からのムーブアウト」とも呼ばれることもある)所有権の移動によって、メモリをより長い間生存させられます。複雑な例は後ほど解説します。