AICon上海|与字节、阿里、腾讯等企业共同探索Agent 时代的落地应用 了解详情
写点什么

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

  • 2015-10-08
  • 本文字数:1579 字

    阅读完需:约 5 分钟

来自微软的 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:001771
用户头像

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

关注

评论

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

Android:三四十岁的大龄程序员如何对后辈评价“太水技术低

android 程序员 移动开发

Android面试反思:开发5年crud背景,惨遭字节阿里双挂,网站开发前后端分离

android 程序员 移动开发

Android面试题之Broadcast Receiver篇,你们觉得作为一名程序员最大的悲哀是什么

android 程序员 移动开发

Android高阶:了解这些知识点,学习Binder就不成问题(1)

android 程序员 移动开发

Android:年过35岁的程序员还有出路吗?面试了一个-46-岁程序员后

android 程序员 移动开发

Android面试必问之Binder进程间通信机制,大厂喜欢从哪些角度考你呢?看完这篇你就懂啦

android 程序员 移动开发

Android面试抱佛脚:进程间通讯学习,从Binder使用看起

android 程序员 移动开发

Android面试题之性能优化篇,当上项目经理才知道

android 程序员 移动开发

Android面试:一个进程有多少个-Context-对象?看似初级的问题

android 程序员 移动开发

Android面试:计算机网络面试知识点系统总结,拔剑金九银十

android 程序员 移动开发

Android面试|任何东西只要够深,都是一把刀!性能优化都没搞好就别想着去找对象了

android 程序员 移动开发

Android高工面试(难度:四星,2021大厂Android知识点总结

android 程序员 移动开发

Apache APISIX 社区周报 | 2021 10.15-10.31

API7.ai 技术团队

API网关 社区周报 Apache APISIX

Android面试:计算机网络面试知识点系统总结,拔剑金九银十(1)

android 程序员 移动开发

Android高阶:了解这些知识点,学习Binder就不成问题,androidapp开发教程推荐

android 程序员 移动开发

Android面试主题整理合集(一),android开发前景

android 程序员 移动开发

Android面试题之性能优化篇(2),安卓高级开发面试题

android 程序员 移动开发

Android题集四大组件之Content provider、BroadcastReceiver

android 程序员 移动开发

Android高级工程师BAT面试题及知识点整理大全(Java基础+Android

android 程序员 移动开发

Android高级面试题大全(持续更新中),字节跳动厂内部超高质量Flutter+Kotlin笔记

android 程序员 移动开发

Android面试官,面试时总喜欢挖基础坑,整理了26道面试题牢固你基础

android 程序员 移动开发

Android面试指南(三),kotlin匿名内部类写法

android 程序员 移动开发

Android高工面试(难度:四星(1),2021Android高级面试题总结

android 程序员 移动开发

Android面经分享:我是如何拿到腾讯头条美团小米的offer从小厂跳到大厂的?

android 程序员 移动开发

Android面试复盘:认真刷题,掌握原理很重要,【深夜思考】

android 程序员 移动开发

一个程序员眼中的项目经理

神策技术社区

OKR 项目经理

Android面试必备知识点:Android中Handler八大问题汇总

android 程序员 移动开发

Android面试题之动画+事件处理篇,腾讯、美团Android面试经验分享

android 程序员 移动开发

Android面试官:看你简历上写熟悉-AIDL,说一说-oneway-吧

android 程序员 移动开发

Android面试题之性能优化篇(1),移动开发工程师的岗位职责

android 程序员 移动开发

Android音视频--H,flutter小程序开发

android 程序员 移动开发

关于是否在C#中加入不可空引用类型的争论_.NET_Pierre-Luc Maheu_InfoQ精选文章