• ← 前回
• 連載 INDEX
• 次回 →

　C# 7として提案されている文法の中には大小さまざまなものがある。今回紹介するのはその中では小さめの機能になる。「式を増やす」という、利便性の向上を目的としたものである。

式

　C#に限らず、プログラミング言語の文法要素には大きく分けて式（expression）とステートメント（statement： 文法の文脈では「平叙文」。断定形の文章）がある。これらには、表1に示すような性質がある。

　C#における例をいくつか表2に示す。

　ひと言でいうと、戻り値を返せるなら式になっている方が便利である。その結果、新しい言語ほど、ステートメントを減らして式を増やす傾向にある。関数型言語にカテゴライズされるようなプログラミング言語ではもともとその傾向が強かったが、近年ではどんなパラダイムの言語であろうと式を好むようになっている。

　C#も例にもれず、C# 3.0やC# 6で、いくつか式として書けるものが増えている。いくつかの例を表3に挙げよう。

　そして、C# 7でも、式にできるものが増える予定である。

式への抵抗感

　式はどこにでも書けて便利と説明したが、その一方で、どこにでも書けすぎるために、読みづらいコードも書けてしまう。それを嫌って、式が増えることに抵抗を感じる開発者もいまだに見受けられる（ベテランの方に多い傾向に見える）。

　それでも、式しか書けない場所が多い以上、ステートメントとしてしか書けない構文が多いことはよくないというのが筆者の意見だ。嫌なコードを書けてしまう問題よりも、そもそも書く手段が全くないことの方が問題は大きい。

　「書けてしまうから嫌」というなら、ステートメントだってひどいものである。書く人が書けば、{}の入れ子でソースコードはどんどん右側にずれていく。例として、ちょっとした総当たり計算を挙げよう。少々懐かしいネタではあるが、「send+more=money」という覆面算を解く問題がはやったことがある。そのとき、クエリ式（他のプログラミング言語だと、リストモナドやリスト内包）を使ったものと、ステートメントを使ったものの比較がよく取り上げられた。クエリ式を使うと以下のように書ける。

　一方、ステートメントで書くと以下のようになるだろう。もちろん、{}を省略したり、無理やりインデントをなくしたりすれば多少はすっきりするが、コード成型ツールをかけるたびに再びこのインデントがかかったりする。

　ステートメントなら良いというものではない。

　「式は読みづらい」というのも、それは「式の書き方を知らないせい」ということだってある。よくやり玉に挙げられるのが条件演算子?:だが、これだって、以下のように書けば意外ときれいなものである。条件 ? 値 :を繰り返すのだ。これなら、if-elseステートメントで書くほどのものではないだろう。

C# 7で提案されている式

　前振りが長くなったがここからが本題で、C# 7での提案についての話に入る。以下のようなものが提案されている。

• throw式
• switch式
• 宣言式
• シーケンス式

　それぞれ説明していこう。

throw

　1つ目は、例外のthrowを式にしようというものである。前述の通り、式にするためには戻り値が必要である。つまり、throwの戻り値がどうなるべきかという話に帰結する。

throw式

　ここでまず思い起こしてほしいのは、戻り値の型によらず、throwステートメントをもってメソッドを抜けられるということである。例えば、以下のメソッドはいずれもコンパイルできる。

　このことから、例外のthrowは「どんな型にでも変換可能な型」を戻り値に持つと考えて差し支えない。この考え方を認めれば、これまでthrowステートメントだったものは、そのままでthrow式になる。

　もっとも、throwが式になってうれしい場面は限られていて、以下の4つである。

1. 条件演算子?:の第2オペランドと第3オペランド：
   x >= 0 ? x : throw new ArgumentException();
2. null結合演算子??の第2オペランド：
   x ?? throw new ArgumentException();
3. 式形式の関数メンバー：
   void NeverReturn() => throw new NotSupportedException();
4. （後述する）switch式の中

　C# 7では、この4カ所でのみ、throwを式として書けるようにする方向で検討が進んでいる。

　ちなみに、「どんな型にでも変換可能な型」を「bottom型」（最下部の型、全ての型の派生扱い）と呼ぶことがある。この逆は「どんな型からでも変換可能な型」で、「top型」（最上部の型、全ての型の基底扱い）と呼び、C#の場合はobject型がこれに当たる。つまり、throw式が返す値の型はobject型の対極ということになる。

never型

　throw式から一歩進めて、「必ず例外をthrowするメソッドの戻り値」を考えてみよう。

　例外には、任意のメソッドを抜けるのに使えるという性質に加えて、throwステートメントから後ろは実行されなくなる（returnステートメントやyield breakステートメントと同じ）性質がある。この性質はコンパイラーも理解していて、適切なコード診断をしてくれる。

　これに対して、例外をthrowする部分をメソッドに切り出すことを考えよう。現状だと以下のようになる。NeverReturnメソッドは常に例外をthrowするメソッドなので、そのメソッド呼び出しから後ろは実行されないはずだが、コンパイラーにはそれが分からず、各種診断が働かない。

　この問題の解決策として、「常に例外をthrowするから、そこから後ろは実行されない」ということを表す型が欲しい。こういう型として、never型という提案が出ている。never型とは以下のようなものである。

• 常に例外を返す式の戻り値を表す
• 任意の型に変換可能
• この型を返すメソッドを呼び出すと、そこから後ろは実行されない

　これを使うと、先ほどのコードは以下のように書き換えられる。

　他のプログラミング言語では、ScalaがNothing型という名前で同様の型を持っている。C#への導入に当たっても、neverの他にbottom、nothingなどの名前が検討されたが、「後ろが実行されない」という性質が名前に現れるよう、neverが最有力となっている。

　never型の実現方法は2種類ある。

1. voidのメソッドに、NeverReturnといったような名前の属性を付ける
2. .NETランタイム側にnever型を表す特別な型を足してもらう

　1のやり方であれば、C#コンパイラーだけで完結していて、近い将来に実装できる可能性が高い。一方で、ジェネリックの変性に対応できないなどの問題があり、1の方式での実装は見送られることになりそうだ。

　従って2のやり方が有力ではあるが、これには.NETランタイムのレベルで手を入れる必要がある。.NETランタイム側にはこれよりも優先度の高いタスクが山積みで、never型の実装に取り掛かれるのはだいぶ先になるだろう。前節のthrow式だけでも十分な利便性を得られるということもあり、never型はしばらく日の目を見なさそうである。

式形式のswitch（match式）

　続いてはswitchの式化だ。これまでのC#でも、if-elseステートメントやループに相当する処理を式で書ける構文がある。表4に示すように、条件演算子?:やLINQがそれに当たる。

　一方で、switch相当の式はこれまでのC#にはなかった。また、次回以降で説明するパターンマッチングが登場すると、switchの利用頻度が増えることが予想される。そこで、switch相当の式が提案されている。現状の最有力候補の文法例は以下のようになっている。

　他の候補としては、以下のような案が出ている。

• ステートメントとの弁別のために、switchの代わりにmatchキーワードを使う
• switchの後ろの()を必須にするかどうか
• 各caseの区切りに, を使うかどうか

完備性

　このswitch式（あるいはmatch式）を導入するに当たって、問題となるのは値の「完備性」（completeness）である。ここでいう完備というのは、「全てのパターンを網羅している」というような意味である。C#は完備性のチェックが緩く、switch（今後導入されるswitch式に限らず、既存のswitchステートメントでも）を使う上でもたびたび問題となる。

　例えば、C#では、bool型はtrueもしくはfalseのいずれかの値しか取らない。にもかかわらず、以下のswitchステートメントはコンパイルエラーとなる。

　true、false以外のパターンがくると、returnで値を返すことなくメソッドを抜けてしまうので、「値を返さないコード パスがあります」というエラーを起こす。しかし、そんなパターンは本来あり得ないはずである。すなわち、

• bool型はtrueとfalseの2つの値で完備（全パターン網羅している）
• 完備性のチェックが正しく機能していれば、上記のコードはコンパイルできるはず：
  • コンパイルできないのは完備性のチェックが緩いから

ということだ。bool型以上に問題となるのは列挙型だろう。C#の列挙型は特に完備性のチェックが難しい。例えば以下のようなコードを見てもらえれば、このことが分かるだろう。

　列挙型の定義時に用意したのとは別の値をいくらでも無制限に使えてしまうため、全パターンの網羅は不可能である。

　残念ながら、今のところこの完備性チェックの緩さは解決できず、default句を必ず書いてしのぐことになる。例えば、上記コードは以下のように書き直す必要がある。

　switch式の場合はどうだろうか。繰り返しになるが、式には戻り値が必須である。幸い、ちょうど前節で説明した通り、throwも式になり戻り値を返せる（返したものと見なせる）ようになったので、これをさっそく使うことになる。

　throw式でごまかすのではなく、完備性チェック自体についても一応検討課題には挙がっている。ただ、bool型はともかく、列挙型への対応は難しそうだ。

宣言式

　次の「式化」は、変数宣言である。変数を宣言すると同時に変数の値をそのまま返す、宣言式（declaration expressions）というものが提案されている。例えば以下のようなコードを書ける。

　要するに、ちょっとした一時変数を式の中で宣言でき、このためだけにステートメントを書く必要がなくなる。

　宣言式は、一度はC# 6向けに検討されていた。しかしその後、C# 6のリリース直前になって、パターンマッチング（次回以降で説明）のアイデアが生まれ、それと一緒にC# 7以降に仕切り直すことになった。

　パターンマッチングが入る前には、以下のようなコードで宣言式が有用ではないかといわれていた。

　しかしこの用途での宣言式はパターンマッチングに置き換えられることになる。詳細は次回以降で説明するが、以下のように書けるようになるだろう。

　私見として、この他で有用と思われる用途は、outパラメーターと番兵型ループの2つである。表5にこれらの例を示そう。

　この例を見てもらえれば、単に変数宣言ステートメントが1つ減るだけではないことが分かるだろう。従来の書き方では、型推論（varの利用）ができないのに対して、宣言式を使えばそれができる。また、変数のスコープも短くできる。

　ちなみに、現状のディスカッションの様子を見るに、もしかすると、outパラメーターに対する宣言式（通称「out var」）だけ先に実装するかもしれないそうだ。前述の通り、宣言式の主な用途の1つがパターンマッチングに置き換わり、番兵型ループはそうめったに書くものではないことから、残る主な用途はout varのみとなるからである。

　ただ、outパラメーターからタプル（次回以降で説明）への自動変換も検討項目に上がっていて、それがあればout varすら要らなくなる可能性がある。例えば、int.TryParseであれば、以下のようなコードが認められるようになるかもしれない。

　あるいはパターンマッチングを使った以下のような書き方もできるようになるかもしれない。

　ということで、実はそれほど大きな需要は残らないのだが、入って困ることもそう多くなく、取りあえずはC# 7に入りそうである。

宣言式で定義した変数のスコープ

　宣言式では、変数のスコープは原則として、「直近のステートメント内」となる予定だ。例えば以下のコードでは、3つのステートメント内のいずれにもxという変数があるが、それぞれ別の変数となる。

　「原則として」といったのは、if-elseステートメントだけ例外となるからだ。if-elseステートメントでは、ifの条件式内で宣言した変数は、if側のブロックでだけ使え、else側からは使えない。先ほど「パターンマッチングに置き換えられそう」だと言ってお見せした例をあらためて出すが、以下のようなコードを書きたくなることがあるだろう。

　この例のように、ifごとに別スコープを持ちたいという要求の方が、elseも同スコープにする要求よりも多かったようだ。

シーケンス式

　最後に紹介するのはシーケンス式（sequence expressions）だ。少し名前が分かりづらい（将来的に名称変更の可能性も結構あると思われる）が、「1つの()内に、;区切りで複数の式を並べて、最後の式の値を返す」というものだ（名前から想像するかもしれないが、IEnumerableを返すような何かではない）。例えば以下のようなコードを書ける。

　この構文は、要するにC言語のコンマ演算子相当の機能だ。区切り文字に,ではなく;を使うのは、パラメーターリストやタプル（次回以降で説明）との区別のためである。

　前節の通り、宣言式で定義した変数のスコープはかなり短い。そのため、このような1つの式内に複数の式を並べられる構文が必要になる。

まとめ

　近年、プログラミング言語の構文はステートメントよりも式を好む傾向にある。C#もその例にもれず、どんどん式を増やしている。C# 7では、以下のようなものが提案されている。

• throw式
• switch式
• 宣言式
• シーケンス式

　これらには、パターンマッチングやタプルなど、他の構文との兼ね合いもあって、そちらが安定してから調整が入る可能性も高い。

　式が増えることによって、手短に書けるコードが増えるだろう。便利すぎることで1行に何でも詰め込んだようなひどいコードが生産されるという懸念もあるが、手短なコードを書く手段がないよりはいいだろう。

• ← 前回
• ▼ この記事の連載 INDEX ▼ 連載 RSS
• 次回 →