如果非期望值是问题所在的话，那么我们就应该努力消除它们。尽管我们几乎从未期望过null（空），然而类型系统却强迫我们装出一副很需要它的样子。——Craig
尽管这句话已经被.NET 开发者在这些年来讲过无数次。然而修正此问题并非易事，不仅仅是在变量上拍个属性或其他修饰那么简单。更严峻的挑战之一就是，要是T为非可空引用类型的话，那么default<T>该如何处理。Craig 写道，
这里的根本问题在于 C#中根深蒂固的假设：该假设即每种类型都有默认值。试想一下：如果
T没有（或可能没有获得）默认值，那么编译器在计算default(T)、初始化类型 T 的字段、或初始化某个类型 T 的新数组中的数组项时就会无值可用。由于一谈到非可空引用类型就会涉及此问题，尽管某些引用类型拥有适当的非空默认值（例如非空字符串类型的默认值可能是空字符串），然而对于大多数引用类型而言却并非如此。试想一下：IEnumerator<int>的默认非空值是什么？IObservable<bool>呢？UserControl呢？NetworkStream呢？答案很简单，它们没有任何默认非空值。而你能做的最好方法就是，给出某种模仿实例，即一旦你尝试使用该实例就会导致失败……不过我们已经有了那种实例，并称之为null（空）。
在题为非可空类型对 C#：修正十亿美元的错误的文章中，Craig 引入了两个新概念：
T!用于指示类型 T 为非可空类型。这也可以用于普通类型及类型参数。withdefault(T)用于把非可空引用类型参数转变为相应的可空类型参数。
要是需要构建私有字段或数组，就将其类型声明为withdefault(T)，而不是类型T。然后在读取该字段或数组时，可以将其重新强制转换非可空类型T。这种强制转换本身是不安全的，而且倘若没有正确构造就有可能抛出异常，不过一旦成为了非空，开发者便可如鱼得水。要了解这样做所产生的后果，最好还是通过 Craig 文章中的例子来解释。
如果对此主题有兴趣，可以在用户反馈网站上对非空引用类型的建议进行投票。
评论