第63章へようこそ。

今日のテーマは「const generics」です。

第10章で、型をパラメータにする仕組みを見ました。

定義するときには型を決めず、使うときに決める。

要素の型が違うだけで同じ処理を書き直すことは、これでなくなりました。

だが、型パラメータでは抽象化できないものがある。

配列の長さだ。

要素が3つの配列を受け取る関数に、要素が4つの配列は渡せない。

今日扱うのは、なぜ長さが型を分けるのか、その長さをどうやってパラメータにするのか、パラメータに取れる値がなぜ限られるのか、長さを型に残すか実行時に持つかをどう決めるのか、そして型に残すと何が消えるのか、です。

第62章へようこそ。

今日のテーマは「Newtype」です。

第6章で、この形はもう出ています。

中身が同じでも型として別物にするために、タプル構造体で包む。

メートルとキログラムはどちらも中の型が同じでも、片方をもう片方の引数には渡せない。

この手法をニュータイプパターンと呼ぶ、と命名しました。

今日はその先を扱う。

包んだあと、その型に何をさせるかは、まだ何も決まっていない。

包んだ型は、中身の操作を1つも受け継がないからだ。

今日扱うのは、包むと何が消えるのか、消えたもののうち何を通すのか、なぜ包むと外部のトレイトを実装できるのか、中身をそのまま見せる実装をどう判断するのか、そしてこの境界がどこに存在しているのか、です。

第61章へようこそ。

今日のテーマは「Cow」です。

第18章で、文字列を返す関数の戻り値をどう決めるかを見ました。

新しく作ったものを呼び出し側に持ち帰らせるならString、借りたまま返すなら文字列スライス。

戻り値の型は所有権の流れで決まる、と定めた。

この原則で決められない関数がある。

入力をそのまま返すこともあれば、加工したものを返すこともある関数だ。

どちらになるかは、入力を見るまで決まらない。

今日扱うのは、その決まらなさをどう型に持つのか、複製がいつ起きるのか、この型が何を要求するのか、そしてどういう流れで使う形なのか、です。

第60章へようこそ。

今日のテーマは「rayon」です。

rayonは、Cargoの設定ファイルに書いて取り込む外部のクレートです。

コレクションの要素にかける処理を、複数のコアへ分けて走らせる。

現在のCPUには、コアが複数ある。

だが、イテレータで要素を順に処理するコードは、そのうちの1つしか使わない。

要素が100万個あっても、残りのコアはなにも進めていない。

rayonが引き受けるのは、この使われていないコアへ要素を配り、かかる時間を減らすことだ。

配るには、決めることが増える。

どこで分けるのか。

分けた先で壊れないと誰が確かめるのか。

分けた量が偏ったらどうするのか。

rayonは、これらを書き手が書かなくてよい形で引き受けている。

ただし、分けること自体に代償がある。

今日扱うのは、その引き受け方と代償です。

第59章へようこそ。

今日のテーマは「キャッシュと局所性」です。

第20章で、スタックは速くヒープは遅いと言われるのを分解しました。

差は3つあった。

確保にかかる時間、解放にかかる時間、そしてアクセスの局所性だ。

このうち確保と解放は、アロケータの手順の差だった。

3つ目だけが、置いてある値を読むこと自体の速さの話だ。

第20章では、スタックはCPUのキャッシュに乗りやすく、ヒープは散らばるから恩恵を受けにくい、とだけ述べた。

今日扱うのは、そのキャッシュが何のためにあるのか、値がどんな単位で運ばれるのか、なぜ連続して並んでいると速いのか、なぜ手数の少ないほうが遅くなることがあるのか、そして型の大きさが速さに何をするのか、です。

第58章へようこそ。

今日のテーマは「FFIと所有権」です。

第56章で、境界の向こうにRustの保証が1つも届かないと見ました。

借用チェッカーも、所有権も、ライフタイムも、ドロップも、境界の手前で止まる。

前章では、型の姿を両側で守る契約にして、を外へ渡せる形に整えた。

だが、外へ渡したは、いつか解放しなければならない。

契約が決めるのは姿までで、後始末までは決めない。

今日扱うのは、が境界を越えるとき何が渡るのか、解放の責任をどう取り決めるのか、ドロップが届かない資源をどう扱うのか、パニックが境界へ届くと何が起きるのか、そしてエラーがどんな形になるのか、です。

第57章へようこそ。

今日のテーマは「repr(C)」です。

第55章で、値はメモリの上ではビット列だと見ました。

その並びをどう読むかを決めるのが型だった。

だが、複数の値を1つにまとめた構造体が、メモリの上でどう並ぶのかは、まだ見ていない。

型は値の読み方だけでなく、構造体のフィールドの置き方も決めている。

今日は、その置き方を見ます。

第56章では、言語をまたぐ境界で、関数が呼び出し規約という機械語レベルの取り決めでつながると見た。

取り決めは、引数と戻り値の受け渡しを決める。

だが取り決めが決めるのは、値の置かれる場所までだ。

値の中身がどんな順序で並んでいるかは、呼び出し規約は決めない。

今日扱うのは、構造体がメモリの上でどう並ぶのか、なぜその姿を外に見せる瞬間に固定が要るのか、レイアウトの約束にはどんな種類があるのか、そして固定に何を差し出すのか、です。

第56章へようこそ。

今日のテーマは「FFI境界」です。

第52章から前章までで、unsafeが解禁する操作を見てきました。

生ポインタのデリファレンス、UnsafeCell、transmute。

どれもunsafeだったが、扱っていたのはRustの中の値だった。

生ポインタが指すのもRustが確保したメモリ、transmuteが読み替えるのもRustの型のビット列。

規則の外側とはいえ、まだRustの世界の中にあった。

今日からは、その外に出ます。

境界の向こうに、別の言語で書かれた関数がある。

Rustから、その関数を呼ぶ。

あるいはRustの関数を、別の言語から呼ばせる。

今日扱うのは、この言語をまたぐ境界が何と呼ばれるか、なぜ別の言語の関数を呼べて、その呼び出しがなぜunsafeになるのか、境界の向こうにRustの保証が届かないこと、そして両方向の境界を安全な抽象で包むこと、です。

第55章へようこそ。

今日のテーマは「transmuteと未定義動作」です。

第52章で、unsafeは規則を破る許可ではなく、保証の主体がコンパイラから人間へ移る境界だと見ました。

第53章と第54章では、その移転が起きる場所を見た。

生ポインタのデリファレンスでは、指す先に有効な値があることを人間が保証した。

UnsafeCellでは、読みと書きが衝突しないことを人間が保証した。

だが、保証に失敗したら何が起きるのかは、まだ確かめていない。

第54章では、前提と食い違ったプログラムの動作に保証は無い、とだけ言った。

今日は、この「保証は無い」の中身を確かめます。

unsafeの中には、人間がどう注意しても越えてはいけない線が引かれている。

その線がどこにあり、越えると何が起きるのか。

入り口は、ビット列を別の型として読み替える関数、transmuteです。

今日扱うのは、transmuteが何をするのか、型が持つ有効性の条件、そして未定義動作とは何か、です。

第54章へようこそ。

今日のテーマは「UnsafeCell」です。

第23章で、内部可変性を見ました。

外側の値に不変参照しか持っていないのに、その内側の値を変更できる仕組み。

RefCellは、借用の検査を実行時に行うことで、それを安全な操作として提供していた。

だが、1つ確かめていないことがある。

借用規則は、不変参照の先を書き換えることを許さない。

そしてRefCell自身も、Rustで書かれた型だ。

同じ規則の下にあるはずのRustのコードが、不変参照の先を書き換えるという動作を、どこかで組み立てていることになる。

第52章で、安全な抽象の内側にはunsafeがあると見ました。

第53章では、その内側で使われる生ポインタを見た。

今日はその2つが実際に働いている場所を、内部可変性で確かめます。

Cell、RefCell、ミューテックス、アトミック型。

これらすべての内側に、たった1つの型がある。

それがUnsafeCellです。

今日扱うのは、不変参照が支えている前提、UnsafeCellがその前提をどう外すのか、安全な型がその上にどう立っているのか、そしてスレッドの境界で何が起きるのか、です。