「null 安全」について

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

• null安全でない言語は、もはやレガシー言語だ - Qiita
• null安全を誤解している人達へのメッセージ - Qiita

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

以下は個人的なメモ。

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

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

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

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

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

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

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

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

ブックマーク

• なぜNullはダメか | To Be Decided
• Null安全な言語をめぐるエトセトラ　その１　３種の「現場」 - Qiita
• null安全はいいぞ。だって、型安全はいいぞ。 - Qiita
• 「null安全」という訳語の背景 - Qiita
• Swiftのエラーハンドリングはなぜ最先端なのか - Qiita