なじみのBarがまた消えた話。
rustのOption型に関する勉強メモ。
diary
bar
また一人のバーテンがなじみのバーからいなくなる。
バーに行くことの楽しみは、その雰囲気やその人との会話を楽しむことである。 ゆえに人がいないことはそのバーが消えたようなものである。(斧の刃を変えるのとは違う。)
人がいなくなればそれだけそこに行く理由がなくなる。
alopecia areata
あごひげの一部に円形脱毛症が発生した。
病院に行って、相談してみる。
今日の勉強
rust
pp. 110-114
- enum
- プログラムにデータ以上の情報をコードかできる
- Option型
- 値が何か、そうでないか
- 値が存在するか不在か(有効でないか)という概念をenumでコード化する
- Rustにはnullがない
- nullのある言語では、変数は、常にnullかそうでないかの二者択一
- nullの表現しようとしている概念
- 何らかの理由で現在無効または存在していないこと
- この概念ではなく特定の実装に問題がある
- 何らかの種類のエラーが出る
Option<T>
と、Some(T)
、None
も初期化(prelude)に含まれている- 明示的にスコープに導入する必要がない
- つまり、
Some
とNone
の前にOption::
の接頭辞なしで使える
- つまり、
<T>
: ジェネリック型None
を使う場合は、Option<T>
と型注釈をしなければならない- なぜなら、Some列挙子が保持する型を
None
だけからは推論できないから
- なぜなら、Some列挙子が保持する型を
- 明示的にスコープに導入する必要がない
Option<T>
と<T>
とは型が異なるOption<T>
値を確実に有効な値かのようには使用できない- なぜならコンパイラにはその使用方法が分からない
T
の型の値- Compilerが常に有効な値かを確認する
- 値がnullではないと安全に想定できる
- 常に自信を持って先に進める
- Compilerが常に有効な値かを確認する
Option<T>
がるとき、- この時のみ、値を保持していない可能性を心配する必要がある
- コンパイラはプログラマが値を使用する前にそのヨナ場面を扱っているか確認する
- nullになる可能性のある値を保持することにこの型を使うことで明示的に同意することになる
- 実際にはnullなのにおうではないかのように想定することへの問題
T
型の処理を使う前には、Option<T>
からT
に返還する必要がある- Some列挙子の値をどのように取り出せばよいか
- ドキュメントを読め
.unwrap()
とか.unwrap_or(default_value)
とかがある
- ドキュメントを読め
- Some列挙子の値をどのように取り出せばよいか
- 各列挙子を処理するコードが欲しい時は
match
式を使おう(フロー制御文法要素となる)- enumの各列挙子によって違うコードが走り
- そのコードがマッチした値の中のデータを使用できるようになる
- matchフロー制御
match
: フロー制御演算子- 一連のパターンに対して値を比較し、
- 最初に適合するパターンで
- マッチしたパターンに応じてコードを実行する
- 一連のパターンに対して値を比較し、
match
式のパワーの由来- パターンの表現力と
- コンパイラが全てのありうるパターンを処理しているか確認してくれる事実
match 式 {
pat => code,
pat => code,
...
}
補足:
- 式は
if
の時とは異なり、任意の型でよい =>
は区切り演算子- 区切り演算子の左がパターン
- パターンは上から順に比較される。
- 区切り演算子の右が何らかのコード(マッチアーム)
- codeは式であることが要求される
- マッチしたアームの式の結果がmatch式全体の戻り値になる
- マッチのアームで複数行を走らせたいときは
{}
でブロックを作ればよい