「null 安全」について

no extension
公理によって与えられる暗黙の制約。この制約が集合の要素同士をしっかり結びつける。単純にしばるのではない、相互に秩序ある関係を結ぶ。言い換えれば――公理によって与えられる制約が構造を生み出しているのだ

「null 安全(null safety)」についての上の記事はなかなか興味深かった。 特に「null安全を誤解している人達へのメッセージ」は事実上の FAQ になっているので是非読んでみてほしい。

以下は個人的なメモ。

「null 参照(null reference)」とは「参照が無効である」ことを示すものだ。 「null 参照」は昔から悩ましい問題である1。 どんなプログラムであれ「null 参照」が存在するのであれば,それを異常系としてハンドリングしなければならない。 しかし大抵の場合,「null 参照」をセットする場所と評価する場所は異なっていて,特にライブラリやフレームワークの中で「null 参照」をセットしている場合は評価されることなくスルーしてしまうことも多い。

オブジェクト指向以前,たとえばアセンブラや C 言語の時代では値と参照は明確に区別されているわけではなく,「それ」を値と見なすのか「参照(addressing/pointer)」と見なすのかは完全にプログラマの責任だった。 それからオブジェクト指向プログラミングが産業分野でも台頭してきたのだが,このパラダイムシフトの過程で「参照(reference)」が言語仕様レベルで意味を持つものとなった。

更に「null 安全」な言語では nullable (null かもしれない)参照と non-null (null を許容しない)参照を明確に区別し未評価の nullable 参照をエラーと見なす。 これは言語仕様の根幹2 に関わるパラダイムシフトのひとつである。

もちろん設計3 などで「null 参照」に起因するバグや脆弱性を回避することは重要である。 「null 参照」をいかにハンドリングするのかは相変わらずプログラマの責任なのだから。 機械がやってくれるのは nullable 参照をそのままアドホックに使いまわさないようコンパイルエラーを出すところまでだ。(ただし,そのコードがコンパイルエラーになるのなら少なくとも製品として世に出ることはない)

私はアセンブラや C 言語(それも K&R バージョン)が全盛のころからの(今やロートル)エンジニアだが,こうして見ていくと人と機械の責務分担が時代ごとに変わっていくのを感じる。

私は将来のプログラミング言語においてはコードに「意図」を記述できるようになっていくと期待している。 nullable 参照と non-null 参照の区別は,コードに「意図」を記述することを言語仕様レベルで規定するものと言える。 これまでもコンパイラヒントとしての annotation のような機能はあったが,そういったものとは質的に異なっている。

コードに「意図」を記述できるようになれば,それ自体が設計書になる。 最近の私は「プログラマも要求定義(開発)から参加すべき」と思っている。 参加してがんがんコードを書けばいい。 百万ページの設計書より「動くコード」のほうが価値が高い。

これまでもそうだったように,コードの「正しさ」を機械の側で担保してくれるならプログラマはもっと違うことに脳みそを振り分けられる。 テストを書かずに済むならそれに越したことはない。 まぁ,最終的に AI がコードを書くようになればプログラマという職業がなくなる(もしくは意味が変わる)かもだけど(笑)

ブックマーク


  1. 「null 参照」による損失を10億ドルと見積もっている人もいる。(「Tony Hoare - Wikipedia」参照) ↩︎

  2. たとえば nullable 参照と non-null 参照を区別するのであればおそらく静的な型付けが要求されるだろうし,型を円滑にドライブするには型推論も必要かもしれない。 ↩︎

  3. たとえば安直に null をセットするのではなく null 状態を扱える適切な value object を使う(デフォルトの動作が決まっているなら null object pattern を構成する)など。そういえば Go 言語ではある型の値が nil でもその型に紐付く関数を参照渡しで呼び出すことができ, nil を正しくハンドリングするのは型で定義された関数側の責務となっている(「関数とポインタ」参照)。そういう意味でも Go 言語は value object を構成するのに都合がいい。なお Go 言語は「null 安全」ではない,残念ながら。 ↩︎