予期しない値が問題であるなら、私たちは、それらを除去するように務めるべきである。Nullはほとんど期待されていないが、型システムは、私たちはそれがあるかのように振る舞うことを強制する。 -- Craig
何らかの形で、この発言が長年数えきれないほどの.NET開発者によって、なされてきた。それにもかかわらず、それを修正するのは、ただ単に変数にアトリビュートや他の装飾をつければ済むような簡単なものではない。幾つもの難しい挑戦の１つは、Tがnull非許容参照型の時に、どのようにdefault<T>を処理すべきかである。氏は以下のように書いている。
この根本的な問題は、C#に深く根付いた仮定である：あらゆる型はデフォルト値を持つ、という仮定。考慮：もしTがデフォルト値を持っていない（あるいは、持っていない可能性がある）なら、default(T)を評価する、T型のフィールドを初期化する、あるいはTの新しい配列中のアイテムを初期化する時に、コンパイラーは、使えるものがない、ということだ。非null参照型では、これは問題である。なぜなら、ある参照型は、まともな非nullデフォルト値（例えば、デフォルトの非null String は空の文字列かもしれない）持っているけれども、大抵は持っていない。考慮：IEnumerator<int>? のデフォルトの非null 値は何か？ IObservable<bool>? UserControlのは? NetworkStreamのは? NetworkStreamのは? 簡単な答えは、それらは持っていない。できることの「最善」は、それを使おうとすると失敗するモックインスタンスを与えることだ。しかし我々は既にそれを持っている。それはnullと呼ばれている。
非Null許容型 対C#：何十億ドルの間違いの修正という題の記事で、氏は2つの新しい概念を導入している。
- T! は型Tを示し、null非許容である。これは、通常の型と同様に型パラメータにも使われる。
- withdefault(T) を使ってnull非許容参照型をそれらのnull許容の対応のものに変換する。
もしあなたが privateなフィールドや配列を作る必要があるなら、それらをT型でなくwithdefault(T)にする。それからフィールドや配列を読む時に、null非許容型Tキャストで戻す。このキャスト自身は安全でないし、もし不適切に構築されたら例外を投げるかもしれない。しかし開発者は、非nullであるそれの下流のものに頼ることが出来る。これの結果は、氏の記事における例で非常に上手く説明されている。
もしこのトピックに興味があるならUserVoiceで非null参照型に投票できる。