您的足迹:首页 > 语言程序 >设计 C# 7

设计 C# 7

当您阅读本文时,C# 7 设计团队已讨论、规划、实验和计划了大约一年之久。在本期中,我将介绍他们一直在探讨的一些观点示例。

在查看时,请注意目前这些仍是要在 C# 7 中体现的观点。虽然一些观点只是经过了团队讨论阶段,但另一些观点已进入了实验实现阶段。无论如何,所有这些概念均尚未最终敲定;很多观点可能会夭折;甚至是那些已经进入后期阶段的观点也可能会在最终确定语言的最后几个阶段被推翻。

声明可以为 null 和不可以为 null 的引用类型

C# 7 讨论中涌现的一些最重要的观点也许与进一步改进 null 的处理方式有关,类似于 C# 6.0 的 null 条件运算符。其中最简单的一项改进可能是,在执行编译器或分析器验证(访问可以为 null 的类型实例)之前,先检查类型实际上是否是不可以为 null 的类型。

如果需要不可以为 null 的引用类型,且您能够完全避免 null,会怎样? 此观点旨在声明引用类型是会允许 null (string?),还是会避免 null (string!)。从理论上讲,甚至可以假定新代码中的所有引用类型声明默认情况下都不可以为 null。然而,正如与我合著“必备 C# 6.0”一书的作者 Eric Lippert 所指出的,确保在编译时引用类型永远不为 null 极为困难 (bit.ly/1Rd5ekS)。

即便如此,还是可以确定类型可能为 null且尚未取消引用的的情况,而无需检查是否是不可以为 null 的类型。或者,也可能发生以下情况:类型可能被分配为 null,尽管声明意图是分配不可以为 null 的类型。

为了扩大受益范围,设计团队正在讨论能否对参数使用不可以为 null 的类型声明,以便自动生成 null 检查(尽管这可能会成为一项可选决定,以避免任何非预期的性能降低,除非可以在编译时这样做)。

(讽刺的是,C# 2.0 添加了可以为 null 的值类型,因为在很多情况下(如从数据库中检索的数据),有必要让整数包含 null 值。现在,在 C# 7 中,设计团队正在考虑支持相反的引用类型。)

对于不可以为 null 的类型(例如,string! 文本)的引用类型支持,另一个有趣考虑是公共中间语言 (CIL) 中的实现情况。两个最常用的方案是将它映射到 NonNullable<T> 类型语法,或者像在 [Nullable] 字符串文本中一样利用属性。后者是目前的首选方法。

元组

元组是设计团队考虑为 C# 7 添加的另一项功能。此主题已在早期语言版本中多次被提出,但仍未予以落实。根据此观点,可以在集合中声明类型,这样声明中就能包含多个值;同样地,方法也可以返回多个值。若要理解此概念,请查看下面的示例代码:

相关推荐

发表评论

路人甲 表情
Ctrl+Enter快速提交

网友评论(0)