public

<p>コードが悪い状態に陥る可能性があるときにパニックさせるのは、推奨されることです。この文脈において、 <em>悪い状態</em>とは、何らかの前提、保証、契約、不変性が破られたことを言い、例を挙げれば、無効な値、 矛盾する値、行方不明な値がコードに渡されることと、さらに以下のいずれか一つ以上の状態であります:</p> <!-- * The bad state is not something that’s *expected* to happen occasionally. * Your code after this point needs to rely on not being in this bad state. * There’s not a good way to encode this information in the types you use. --> <ul> <li>悪い状態がときに起こるとは<em>予想</em>されないとき。</li> <li>この時点以降、この悪い状態にないことを頼りにコードが書かれているとき。</li> <li>使用している型にこの情報をコード化するいい手段がないとき。</li></ul>

誰かが自分のコードを呼び出して筋の通らない値を渡してきたら、最善の選択肢は<code class="hljs">panic!</code>し、 開発段階で修正できるように自分たちのコードにバグがあることをライブラリ使用者に通知することかもしれません。 同様に自分の制御下にない外部コードを呼び出し、修正しようのない無効な状態を返すときに<code class="hljs">panic!</code>はしばしば適切です。

しかし、どんなにコードをうまく書いても起こると予想されますが、悪い状態に達したとき、それでも<code class="hljs">panic!</code>呼び出しをするよりも、 <code class="hljs">Result</code>を返すほうがより適切です。

コードが値に対して処理を行う場合、コードはまず値が合法であることを確認し、 値が合法でなければパニックするべきです。

<em>マッチガード</em>と呼ばれます: アームのパターンをさらに洗練する<code class="hljs">match</code>アーム上のおまけの条件式です。

手短に言えば、パターンの文脈において、<code class="hljs">&amp;</code>は参照にマッチし、その値を返しますが、 <code class="hljs">ref</code>は値にマッチし、それへの参照を返すということなのです。

<code class="hljs">Result</code>値の直後に置かれた<code class="hljs">?</code>は、リスト9-6で<code class="hljs">Result</code>値を処理するために定義した<code class="hljs">match</code>式とほぼ同じように動作します。 <code class="hljs">Result</code>の値が<code class="hljs">Ok</code>なら、<code class="hljs">Ok</code>の中身がこの式から返ってきて、プログラムは継続します。値が<code class="hljs">Err</code>なら、 <code class="hljs">return</code>キーワードを使ったかのように関数全体から<code class="hljs">Err</code>の中身が返ってくるので、 エラー値は呼び出し元のコードに委譲されます。

<code class="hljs">Entry</code>上の<code class="hljs">or_insert</code>メソッドは、対応する<code class="hljs">Entry</code>キーが存在した時にそのキーに対する値への可変参照を返すために定義されており、 もしなかったら、引数をこのキーの新しい値として挿入し、新しい値への可変参照を返します。このテクニックの方が、 そのロジックを自分で書くよりもはるかに綺麗な上に、borrow checkerとも親和性が高くなります。

<code class="hljs">String</code>型は、言語の核として組み込まれるのではなく、Rustの標準ライブラリで提供されますが、伸長可能、 可変、所有権のあるUTF-8エンコードされた文字列型です。RustaceanがRustにおいて「文字列」を指したら、 どちらかではなく、<code class="hljs">String</code>と文字列スライスの<code class="hljs">&amp;str</code>のことを通常意味します。この節は、大方、 <code class="hljs">String</code>についてですが、どちらの型もRustの標準ライブラリで重宝されており、 どちらもUTF-8エンコードされています。

それらの名前が全て<code class="hljs">String</code>か<code class="hljs">Str</code>で終わっているのがわかりますか？所有権ありと借用されたバージョンを指しているのです。 ちょうど以前見かけた<code class="hljs">String</code>と<code class="hljs">&amp;str</code>のようですね。

<code class="hljs">add</code>呼び出しで<code class="hljs">&amp;s2</code>を使える理由は、コンパイラが<code class="hljs">&amp;String</code>引数を<code class="hljs">&amp;str</code>に<em>型強制</em>してくれるためです。 <code class="hljs">add</code>メソッド呼び出しの際、コンパイラは、<em>参照外し型強制</em>というものを使用し、ここでは、 <code class="hljs">&amp;s2</code>を<code class="hljs">&amp;s2[..]</code>に変えるものと考えることができます。参照外し型強制について詳しくは、第15章で議論します。 <code class="hljs">add</code>が<code class="hljs">s</code>引数の所有権を奪わないので、この処理後も<code class="hljs">s2</code>が有効な<code class="hljs">String</code>になるわけです。

<code class="hljs">String</code>は<code class="hljs">Vec&lt;u8&gt;</code>のラッパです

Rustで文字を得るのに<code class="hljs">String</code>に添え字アクセスすることが許されない最後の理由は、 添え字アクセスという処理が常に定数時間(O(1))になると期待されるからです。 しかし、<code class="hljs">String</code>でそのパフォーマンスを保証することはできません。というのも、 合法な文字がいくつあるか決定するのに、最初から添え字まで中身を走査する必要があるからです。

可変参照が参照している値を変更するには、<code class="hljs">+=</code>演算子を使用する前に、 参照外し演算子(<code class="hljs">*</code>)を使用して<code class="hljs">i</code>の値に辿り着かないといけません。

幸運なことに、 enumの列挙子は、同じenumの型の元に定義されるので、ベクタに異なる型の要素を保持する必要が出たら、 enumを定義して使用することができます！

<code class="hljs">mod front_of_house</code>の後にブロックではなくセミコロンを使うと、Rustにモジュールの中身をモジュールと同じ名前をした別のファイルから読み込むように命令します。

関数をスコープに<code class="hljs">use</code>で持ち込む場合、Listing 7-11 のほうが慣例的なやり方です。 関数の親モジュールを<code class="hljs">use</code>で持ち込むことで、関数を呼び出す際、毎回親モジュールを指定しなければならないようにすれば、フルパスを繰り返して書くことを抑えつつ、関数がローカルで定義されていないことを明らかにできます。 Listing 7-13 のコードではどこで<code class="hljs">add_to_waitlist</code>が定義されたのかが不明瞭です。

<code class="hljs">pub use</code>を使うことで、ある構造でコードを書きつつも、別の構造で公開するということが可能になります。 こうすることで、私達のライブラリを、ライブラリを開発するプログラマにとっても、ライブラリを呼び出すプログラマにとっても、よく整理されたものとすることができます。

Rustにおけるプライバシーは、「あらゆる要素（関数、メソッド、構造体、enum、モジュールおよび定数）は標準では非公開」というやり方で動いています。