自動的に追加されます。値で表現できる範囲は、列挙型そのもので表現できる範囲以上になるため、変換できない可能性も考えられます。失敗可能イニシャライザーになっています。オプショナルな値として取得されます。セットで使って、変換処理と成否判定を一緒にするのが一般的になると思います。値として文字列を使うこともできます。定義した上で、それぞれの列挙子に対応する値を文字列リテラルで明記します。型のとき、具体的な値を省略すると、列挙しと同じ記述の文字列リテラルが指定されたのと同じになります。上記の定義と次の定義は同じになります。値の値も変更されます。注意が必要になってきます。値の使用は慎重に行う必要がありそうです。値は使わない方が賢明なようにも感じます。値でしか列挙子を表現できない環境とブリッジしなければならないみたいな、どうしても避けられない環境制約があるときに限って使う、みたいなくらいでちょうど良いのかもしれません。いう意味合いになっているように見えます。値を持たせた列挙型は、自動的にこのプロトコルに準拠することになります。ところが、捉える上での大事なポイントみたいです。それをよく表現していると思うのが、たとえばこんな場面です。慣れてくるほどに感じられる気がします。値のどういったところに注目して判断したら良いのか、そんなあたりを考えてみたいと思います。値として文字列型の値を持つ、次の列挙子を想定して話を進めてみることにします。値を扱うことによって、列挙型の最大のメリットではないかと思う「網羅性の保証」が完全に消失してしまうところです。列挙子を使った篩い分け例えば、列挙子を使った篩い分けであれば、次のように書けます。print("俗語")}この書き方は一般的な書き方ですが、これまでにも述べた通り、大きなメリットがあって、すべての場面が網羅されていることが保証されています。ことが、このコードから伝わってきます。値を使って行うことも可能です。fatalError("予期しない場面を検出しました")}これは、先ほどの列挙紙を直接使った場合とまったく同じ動作をします。完全に文字列型で扱うため、どんな文字列を取り得るか、コンパイラーが判断する術がなくなります。記載する必要が出てきます。これ以外の場面は有り得ないにも関わらず。必要ないコードが書かれているだけなら、可読性を低下するのを除けば、致命的な実行時エラーなどは発生しないので良いですが、次の条件判定が間違っていること、漏れなくつぶさに見つけられるでしょうか。fatalError("予期しない場面を検出しました")}間違いは5箇所です。行が実行されます)4つ目の条件が、大文字で始まっていますこれらを瞬時に見つけられる人ってたぶん稀で、間違っていそうとアタリをつけて意識を集中させて探して、やっと見つけることができると思います。値を使わずに列挙子を直接扱うだけで、コンパイラーが全て確実に見つけてくれるのは素晴らしいことです。なんじゃないかなって感じます。値を扱う利点というのはあるのだろうか、そんなところが今回の話の大きなテーマです。値から列挙型を作り出す分には、変換できたかどうかを判定できる分、網羅性の欠落は、最終的には問題にはならなさそうな気がします。"honorifics")具体的に、例えばこのような変換ミスが発生する可能性が出てきます。値からの変換イニシャライザーは失敗可能イニシャライザーとして規定されているので『もしかすると変換できないかもしれない』ことは明らかです。値から列挙型の値を作る上での大事なポイントになってきそうに思います。それさえできれば、あとは列挙型ならではのメリットを享受することが可能になります。値を必要になるまで変換せずに、変数などでしばらく持って回るのは、得策ではないように思います。広くなってしまうため、変換できない場面を想定せざるをえないというのが実際問題としてあるだけであって。よる網羅性検査などのメリットが得られるようになります。値が何かの手違いで不適切だったりしたときに、できるだけ早くそれを察知できるというメリットにもなります。値を取得したらすぐに列挙型に変換すれば、手違いが発生した現場をすぐに検出できます。間違いの現場を捉えられれば、原因も掴みやすいですし、値が確定していない不安定な状況を先送りせずに済むので、不要なバグを水面下で引きずる可能性が相当少なくなるのが期待できます。検討することが重要なように思います。こと自体が問題のように思えるためです。値に変換できるのも然ることながら、文字列から列挙型を作れるということになります。値に対応させる以上はどこかでそれを使うことになるはずです。なると、必ずどこかで文字列から列挙型の値への変換が発生し、そこで変換できない可能性が発生するのは、先ほど記した通りです。