|
|
如何评价即将发布的 C# 9.0？
关注者
284
被浏览
200,059
42 个回答
知乎用户
自问自答，主要目的不在评价 C# 9.0，而在于解释一些吐槽点所在之处，以及给出改进方法和反馈渠道。
records
关于 records，目前为止官方实现的唯一写法只有：
data class(string FirstName, string LastName);
data struct(string FirstName, string LastName);
即：Positional Records，而且官方还在考虑将
data
关键字更换为
record
。
大会上说的那些很多只是 prototype，其他的那些比如
init
、不可变性等等目前官方还在讨论到底应该怎么写，因此那些几乎还没有开始实现，从社区的建议也不断地被采纳和参考。
如果不满意的话，建议大家尽快去 C# 语言设计仓库发 issue 提出自己的建议或问题等让官方看到，借此改进 C# 9 records 的提案，而不是在木已成舟后才后悔：
关于 records 的讨论主要在：
以及 records 是一系列特性的集合，比如 Positional Records、Nominal Records、Value-based Equality、With Experssion 等等，目前官方只 ship 了 Positional Records 和 With Expression，其他的讨论其实也有对应的 issue，如果有意见但是实在找不到对应 issue 的话可以直接发新的 issue。
and
、
or
和
not
模式
关于
and
、
or
和
not
这一点，因为
||
、
&&
和
!
甚至是
|
、
&
和
~
本来就具有表达式语义的，如果模式匹配沿用这些操作符就会造成二义性，考虑以下代码：
var a = foo switch
true || false => 1,
_ => 2
请问如果
foo
是
false
，
a
的值应该是什么呢？
还有：
var a = foo switch
4 | 5 => 1,
_ => 2
请问如果
foo
是
4
，
a
的值应该是什么呢？
因此，唯一的解决方案就是仅在模式匹配中引入新的
and
、
or
和
not
上下文关键字，避免歧义性。
另外，为什么这三个关键字只能用在模式匹配呢？因为这样会导致 breaking changes，使得之前用了
and
、
or
或
not
作为标识符的代码不能通过编译，比如下列代码：
var and = 1;
if (and == 5) { ... }
如果允许了
and
、
or
或
not
出现在其他非模式匹配的地方，那么上述本来能通过编译的代码将不再能通过编译，会造成很大的问题。
该特性讨论地址：
返回值协变及 Type Classes
首先，返回值协变只能用于
class
而不能用于
interface
。
其次，这个并不是为 Type Classes 铺路的，Type Classes 的 prototype 实现和讨论分别在下面两个链接里，并且 target 到了明年的 C# 10：
最后
C# 9 的所有候选特性都在这里，对任何特性有意见都可以去反馈，整个流程完全是透明的：
以及放一个语言特性计划板，对新特性或以后的计划有任何问题都可以直接在里面找并参与讨论：
WorkingSet 表示近期在关注中的特性，Backlog 表示有计划但是还没开始关注的特性。
最后再放一个 C# 语言设计会议记录：
所有的特性讨论和结论都完整地记录在了这里面。
油女一族 ⎝知名Bug制造专家
一言难尽，我就挑一些出来说吧。
- 记录和DU等待很久，现在记录先出来了，但是让记录同时支持with 语法 和 字段可变则不是个好主意。取消字段可变可以让记录有更明确的用场，而越简单的东西越有利于优化，同时会让代码更安全。
- 模式匹配增加了关系模式。这样的符号混在一起可读性不是很高，借助未来的着色帮助可能会好一点（假如有），我没有认真去研究，不知道支持非常量或者非只读变量不。如果不限制，相信就有人会写出一堆副作用的代码来，把 when Guard 混进去不是件好事。
- 简单类型的模式模式就有点不知所谓了，为了省一个符号，将来要付出代价的，想扩展另一些更强的模式匹配会有麻烦。
- 模式匹配的逻辑模式，之前看错了，应该是跟 F# 一样的。可以这样用
value switch {
int or long => 0, // 用了简单类型，真香
_ => 1
这个好的，原来我就不满为什么没有逗号来匹配两种情况，现在好了，同时增加了
or
和
and
。
5. override 时候允许协变。这是我在尝试实现类类型时候碰到的瓶颈之一。也许是为将来实现类类型做铺垫，但是如果尝试从这条路来做，而不是从根上解决的话，我也不太满意。同时我也怀疑，这样真的好吗？
6.代码生成器，框架设计者应该都喜闻乐见，虽然使用时候不会很轻松，但是起码有这功能了。
总之，C#现在是越来越“灵活”了。但是灵活和准确表达之间总是背道而驰的。准确表达可以让编译器更清楚你要做什么，也可以减小程序员的智力负担。我觉得语法的更进，不应该停留在让你少敲几个字符的层面上。如果增加语法只是从一种写法变成另一种写法，而没有引进一个独立概念模型，那么程序员的代码也只是从一堆屎山变成另一堆更大的屎山而已，毕竟不正交的语法设计会让回字有多种写法，如果使用它们时候区别不大，程序员凭喜欢选择会造成很大的困惑。
关于模式匹配那里，不需要用 if, 本来是个when guard:
value switch {
x when x < 3000 => 10.00m - 2.00m,
_ => ...
现在变成
value switch {
< 3000 => 10.00m - 2.00m,
_ => ...