关于是否在C#中加入不可空引用类型的争论

2015 年 10 月 08 日

来自微软的 Mads Togersen 在近期所提出的一条提议,即在 C#语言中加入对不可空引用类型的支持在.NET 社区中引起了热烈的争论。人们对此提议的反应大相径庭,既有人对此表示赞赏,也不乏倾向于保持现状的意见。

在 Reddit 上,这条提议引起了大量关于向后兼容性方面的疑问。Strilanc 认为,如果应用了这一特性,按照这条提议的做法无法实现现有应用的平滑过渡

这条提议还有待改进,它对于保证二进制兼容性、源代码兼容性以及现有代码的渐进式过渡方面还存在着一些考虑不周的情况。

  1. 该提议造成了程序集级别上的意义转变,每个引用类型的名称意义都将变为不可空。它将一次性让整个项目级别的代码块的意义发生巨大的改变,要顺利地完成这一过程,需要付出大量的成本并承担极高的风险。这一点非常糟糕。
  2. 该提议在泛型方面还有待改善,它完全没有提及在大量的泛型代码中将不允许使用 default(T) 这一事实。这一点对于现有的代码将产生怎样的影响?可以采取哪些解决手段?那些确实需要这一功能的类型又将如何实现 default(T) 的效果?这些问题都还没有进行充分的探索。
  3. 这种方式岂不是会允许数组包含一些无效的初始值吗?这种做法公然地违反了类型系统的意义,既然如此,何必还要将它硬塞进去呢?

还有一方面的顾虑在于对于外部类库的向后兼容性,正如 Maplemario 所说:

那么问题来了。假设我要使用一个旧的类库,其中的函数都返回类型 T,无法它是否是可空的。现在,该提议产生了语言范式上的转变,它将 T 视为不可空的 T 类型,而我所调用的某个函数却有可能返回 null(在编写这个类库时,这种做法是合法的)。如果这种场景在整个程序中是一个偶尔才需要进行测试的用例,那么在理想的情况下,项目文档将指出这一点,而我在阅读文档后就知道应当在调用时进行空检查。或者因为我记得这是一段陈旧的代码,因此我将始终进行空检查。而在实际情况下,由于“T 即代表着不可空的 T”,因此我无需再进行空检查。如此一来,这段程序就会在我对空指针进行取值时崩溃。

人们也在热烈地讨论这一提议的替代方案。用户 00Davo 倾向于使用一种新的符号,以表示不可空类型

我也乐于让纯粹的 T 类型总是代表不可空的引用,而只有 T? 才能够接受空值,但这种改变对于向后兼容性来说就是一场恶梦。如果能引入一个全新的、明确的不可空引用符号,那么向后兼容性就会坚挺许多。比如使用 T! 符号,如何?

而在有些人看来,实现这一提议会造成的问题过多了。Number127 建议将静态分析作为一种替代方案

遗憾的是,目前来看,如果要以一种优雅的方法引入不可空引用类型,会造成过多的兼容性问题。我认为最有希望的替代方案是在维持目前的类型系统的情况下,通过静态分析技术以检查某个引用是否能够保证不为空。

在 GitHub 的页面上,人们同样在讨论静态分析这一方案。Paulo Morgado 对此进行了更进一步的阐述,他表示这条提议其实就代表了静态分析的使用

如果我的理解没错,这条提议其实就是一种增强版的方法契约而已。编译器在这里不会做出什么担保,更不用说运行时了。编译器所做的无非是对于那些声明为可空的变量进行数据流的分析而已。

在另一个话题中,Tomas Petricek 指出:这条提议必须考虑到其它 CLR 语言,例如 F#:

该提议能否详细地说明一下如何在 CLR 级别保存可空的标注信息?(我猜测这些标注应当并不具有运行时的意义,它们只会表现为某种.NET
attribute,或某种其它类型的元数据?)

我希望未来某个版本的 F#编译器能够辨识并理解这些标注信息,并定义某种“严格”模式,可空的类型在这种模式中将自动地暴露为 option<'T>
(或者差不多意思的某种类型)。

对于不可空引用类型的争论其实并不新鲜,在过去几年中,对这一问题已经进行了多次讨论。正如原微软的首席开发者 Eric Lippert 所说,在一个已具有15 年历史的语言中添加不可空引用是一项浩大的工程

查看英文原文 Debate: Adding Non-nullable References to C#

2015 年 10 月 08 日 19:001043
用户头像

发布了 428 篇内容, 共 148.0 次阅读, 收获喜欢 20 次。

关注

评论

发布
暂无评论
发现更多内容

架构师训练营第一期 - 第五周课后 - 作业二

极客大学架构师训练营

极客时间 - 架构师一期 - 第五周作业

_

极客大学架构师训练营 第五周

科大讯飞开发者大赛:首届X光安检图像识别挑战赛结果出炉

Talk A.I.

甲方日常 37

句子

工作 随笔杂谈 日常

架构训练营第一周学习总结

Jack

食堂就餐卡系统设计

Jack

架构设计

成为架构师 - 架构师训练营第01周

陈永龙Vincent

数字货币可能重构全球货币体系

CECBC区块链专委会

数字货币 金融

架构师训练营第一周学习总结

韩儿

什么! 你还在使用 if (xxx != null)做NullPointerException判断?

刘超

Java Optional

知识视频创作者何去何从,百度给出解答

脑极体

化身“监工”的AI,我们该如何相处?

脑极体

极客大学架构师训练营2期第一周 作业

渡江卿

c++nullptr(空指针常量)、constexpr(常量表达式)

良知犹存

c++

《我想进大厂》之JVM夺命连环10问

艾小仙

Java 编程语言 JVM jvm调优

架构师训练营第 1 期第五周总结

Leo乐

极客大学架构师训练营

架构师训练营第五周作业

听夜雨

极客大学架构师训练营

架构师训练营第一周总结

小兵

区块链支付系统开发源码,usdt承兑支付平台搭建

WX13823153201

区块链支付系统开发

前端更应懂产品

执鸢者

产品 腾讯 前端

这本书可能是给用户最好的礼物——专栏《软件交付那些事儿》上线

刘华Kenneth

架构师训练营1期第5周作业--一致性哈希算法

木头发芽

惠普中国(HPE)技术总监教你如何做个“火影般”的“架构师”

Java架构师迁哥

Java 程序员 架构

仿生智能 | 初号机的成长之路序章

高翔龙

人工智能 AI 机器人 Robot

《我想进大厂》之Dubbo普普通通9问

艾小仙

Java dubbo RPC HTTP

食堂就餐系统UML图

小兵

政府和企业如何认识到区块链的好处

CECBC区块链专委会

比特币 区块链

架构师训练营第一期 - 第周五课后 - 作业一

极客大学架构师训练营

第五周总结

_

架构师一期 架构师第五周总结

世界上最难的5种编程语言

艾小仙

编程语言 编译 esolang

区块链技术本质再认知

CECBC区块链专委会

区块链 大数据

关于是否在C#中加入不可空引用类型的争论-InfoQ