如果非期望值是问题所在的话,那么我们就应该努力消除它们。尽管我们几乎从未期望过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 文章中的例子来解释。
如果对此主题有兴趣,可以在用户反馈网站上对非空引用类型的建议进行投票。
评论