聞き流しプログラミング言語学習

第111章へようこそ。 今日のテーマは「局所推論」です。 英語ではlocal reasoning、ローカルリーズニングと呼びます。 局所推論とは何か。 「コードの一部分だけを見れば、その部分の正しさを判断できる」ということです。 プログラム全体を頭に入れなくていい。 今見ている関数だけを見れば、その関数が正しいかどうかわかる。 この性質を、局所推論が可能であると言います。 Rustの設計は、この性質を徹底的に追求しています。...

第4章で半加算器と全加算器を紹介しました。 今日は加算器をさらに深掘りします。 実際のCPUではどのように加算が行われているのか。 そして、なぜ加算器の設計が重要なのか。

第110章へようこそ。 今日のテーマは「自己参照の壁」です。 第78章でPinを学びました。 値をメモリ上の位置に固定する仕組み。 自己参照構造体がムーブで壊れる問題を防ぐためにPinが存在する、と説明しました。 今日は、その問題の根をもっと深く掘ります。 なぜ自己参照構造体がRustで難しいのか。 他の言語では普通にできることが、なぜRustでは壁にぶつかるのか。 答えは、Rustの所有権モデルの根幹にある。 所有権とライフタ...

前章では、論理ゲートで足し算ができることを見ました。 でも、その足し算は2進数で行われていました。 1たす1が、2ではなく、繰り上がって10になる世界。 今日は2進数そのものについて掘り下げます。 なぜコンピュータは10進数ではなく2進数を使うのか。 そして、2進数で数をどう表現するのか。

第109章へようこそ。 今日のテーマは「変性」、バリアンスです。 第107章で、借用チェッカーの目を学びました。 第108章で、トレイトオブジェクトとライフタイムの関係を学びました。 今日は、ライフタイムの「代入互換性」を考えます。 ある関数が、あるライフタイムを持つ参照を要求している。 手元には、もっと長いライフタイムを持つ参照がある。 この長い参照を、短い参照の代わりに渡せるか。 直感的には、渡せるはずです。...

前章では、基本的な論理ゲートを学びました。 NOT、AND、OR、XOR、NAND。 でも、これらは単体では単純すぎます。 入力を1つか2つ受け取って、1ビット出力するだけ。 今日は、これらのゲートを組み合わせる話です。 組み合わせることで、驚くほど複雑な機能が生まれます。

第108章へようこそ。 今日のテーマは「ライフタイムとトレイト」です。 第95章で、トレイトオブジェクトを学びました。 具体的な型を消して、dynを付けたトレイトとして扱う。 vtableを通じて、型の名前を知らなくてもメソッドを呼べる。 第13章から第15章で、ライフタイムを学びました。 参照には有効期間がある。参照先より長く生きてはならない。 今日は、この二つが交差する場所を見ます。 トレイトオブジェクトに、ライフタイ...

前章では、トランジスタというスイッチを学びました。 今日は、そのスイッチを組み合わせて「論理」を作ります。 論理ゲート。 これは、0と1を入力として受け取り、何らかのルールで0か1を出力する部品です。 たった4種類の論理ゲートで、コンピュータのすべての計算が可能になります。

第107章へようこそ。 今日のテーマは「借用チェッカーの目」です。 第13章でライフタイムの基本を学びました。 参照は、参照先のデータより先に消えなければならない。 第14章で、関数のライフタイム注釈を学びました。 第15章で、省略規則を学びました。 今日は視点を変えます。 あなたが書いたコードを、コンパイラはどう見ているか。 借用チェッカーは、Rustコンパイラの中でも最も独特な部品です。 他の言語のコンパイラは、型...

前章では、0と1が電圧の高低であることを学びました。 でも、電圧を「高くしたり低くしたり」するには、何かが必要です。 スイッチのようなもの。 今日の主役は「トランジスタ」。 現代のコンピュータを支える、極めて小さな電子部品です。

第106章へようこそ。 今日のテーマは「エラー型の設計」です。 第9章でResult型を学びました。 第64章でエラーハンドリングのパターンを学びました。 第69章でanyhowとthiserrorの使い分けを学びました。 今日は、これらの知識を前提に、エラー型の設計判断を深掘りします。 エラー型の設計で最も重要な問いは、「呼び出し側はこのエラーで何をするか」です。 エラーをログに書いて終了するのか。 エラーの種類に応じて処理を分岐...

コンピュータ基礎学習へようこそ。 コンピュータは0と1で動いている。 これは誰もが聞いたことのある話です。 でも、0と1とは何でしょうか？ 本当に「0」という数字や「1」という数字がどこかにあるのでしょうか？ 今日は、この素朴な疑問に答えます。

第105章へようこそ。 今日のテーマは「型で状態を表現する」です。 第59章で型状態パターンを紹介しました。 ジェネリックパラメータのマーカー型で、状態を型に埋め込むパターン。 今日は、より広い視点で「型による保証」を考えます。 データ構造が、本来ありえない組み合わせを許してしまうことがある。 たとえば、ログインしていないのにメール確認済みになっている。 接続が切れているのにデータを送信しようとしている。 コ...

第104章へようこそ。 今日のテーマは「抽象をどこまで広げるか」です。 ジェネリクスは強力です。 型パラメータを使えば、一つの関数があらゆる型に対応できる。 しかし「あらゆる型」が常に正しいわけではない。 境界が広すぎれば、使い手は何を渡せるのか分からない。 境界が狭すぎれば、不必要に型が制限されて使いにくい。 トレイト境界は、ジェネリクスの広がりに壁を立てる仕組みです。 その壁をどこに立てるかが、設計の判...

第103章へようこそ。 今日のテーマは「閉じた世界と開いた世界」です。 Rustで「複数の種類を一つの型として扱いたい」とき、選択肢が二つあります。 enumで、すべてのバリアントを列挙する。 トレイトオブジェクトで、共通の能力だけを定義する。 どちらでも「異なる種類を統一的に扱う」ことはできます。 しかし、設計の意味がまったく異なる。 enumは、閉じた世界を作ります。 バリアントの一覧は定義の中に固定されている。後...

第102章へようこそ。 今日のテーマは「トレイトの応用設計」です。 ここまで、トレイトシステムの仕組みを深掘りしてきました。 トレイトオブジェクト、ブランケット実装、オーファンルール、マーカートレイト、スーパートレイト、関連型と型パラメータ。 今日は、これらの仕組みを組み合わせた実践的な設計パターンを二つ学びます。 一つは、拡張トレイト。既存の型にメソッドを追加するパターン。 もう一つは、シールドトレイト...

第101章へようこそ。 今日のテーマは「関連型と型パラメータの使い分け」です。 第12章で関連型を紹介しました。 IteratorトレイトのItem型。実装側が一つだけ決定する型。 そこでは、構文としての関連型を学びました。 今日は、設計判断としての関連型に踏み込みます。 トレイトに型を持たせる方法は二つあります。 関連型を使う方法と、型パラメータを使う方法。 Iteratorトレイトは関連型Itemを持っています。 nextメソッドの戻...

第100章へようこそ。 今日のテーマは「スーパートレイト」です。 第98章では、マーカートレイトを学びました。 メソッドを持たず、型の性質を宣言するトレイトでした。 今日は、トレイト同士の階層関係に踏み込みます。 Copyトレイトを実装するには、Cloneが必要でした。 CopyはCloneを前提としている。この関係を、スーパートレイトと呼びます。 CloneはCopyのスーパートレイト。 CopyはCloneのサブトレイト。 この階層関係は、ト...

第99章へようこそ。 今日のテーマは「オーファンルール」です。 第96章では、ブランケット実装を学びました。 条件を満たすすべての型に、トレイトを一括実装する仕組みでした。 今日は、トレイト実装に課せられた制限を学びます。 Rustでは、他のクレートが定義したトレイトを、他のクレートが定義した型に実装することはできません。 たとえば、標準ライブラリのDisplayトレイトを、外部クレートのSomeTypeに対して、自分のクレ...

第98章へようこそ。 今日のテーマは「マーカートレイト」です。 第94章でSizedを学びました。第97章でSendとSyncを学びました。これらには共通点がある。メソッドが一つもない。 Iteratorにはnextがある。Displayにはfmtがある。Dropにはdropがある。 しかしSized、Send、Syncにはメソッドがない。 メソッドがないのに、何のために存在するのか。 型の性質をコンパイラに伝えるためです。「この型はこういう性質を持つ」と宣言する...

第97章へようこそ。 今日のテーマは「所有権がスレッド安全を生む」です。 第42章でSendとSyncに触れました。そこではスレッドの安全性という文脈の中で、名前と基本的な意味を紹介しました。 今日は、SendとSyncをトレイトとして深く見ます。 なぜメソッドが一つもないのか。なぜコンパイラが自動的に実装するのか。そしてなぜ所有権のルールだけでスレッド安全が実現されるのか。 Rustの並行性の安全保証は、ランタイムの仕組み...

第96章へようこそ。 今日のテーマは「ブランケット実装」です。 前章では、トレイトオブジェクトを学びました。 型を消して、トレイトだけで値を扱う仕組みでした。 今日は、トレイトシステムのもう一つの強力な仕組みに踏み込みます。 Displayを実装した型は、to_stringメソッドが使えます。 自分でto_stringを実装した覚えはない。Displayだけを実装した。 なのに、to_stringが手に入っている。 これがブランケット実装です。 「...

第95章へようこそ。 今日のテーマは「型を消す抽象」です。 ジェネリクスは「どんな型でも受け入れる」仕組みでした。 しかしジェネリクスでは、コンパイル時にすべての型が確定します。 コンパイラは、使われる型ごとに専用のコードを生成する。 これが単相化、モノモーフィゼーションです。 では、コンパイル時に型が決まらない場合はどうするか。 設定ファイルの内容に応じて、異なる型のオブジェクトを返したい。 プラグインの...

第94章へようこそ。 今日のテーマは「コンパイラが最初に確認すること」です。 前章でDefaultを学びました。型の持つ性質として、初期値が定義できるかどうか。 今日はもっと根本的な性質を見ます。型のサイズが、コンパイル時に確定しているかどうか。 Rustのコンパイラは、値をスタックに置くとき、その型のサイズを知っている必要があります。 i32なら4バイト。f64なら8バイト。サイズが分かるから、スタックフレームを正しく構...

第93章へようこそ。 今日のテーマは「型の始まりの姿」です。 前章でDropを学びました。値がスコープを抜けるとき、何が起きるか。所有権の終わり。 今日は反対の方向を見ます。値が生まれるとき。型の始まりの姿。 Rustには「何も指定しなかったときの値」を定義するトレイトがあります。Defaultです。 数値型のデフォルトは0。boolのデフォルトはfalse。Stringのデフォルトは空文字列。Vecのデフォルトは空のベクタ。 これは便利...