是否有任何理由不总是使用 C# 8.0 的不可为空的引用类型？

Question

上下文

C# 8.0 具有non-nullable reference types 的这个特性。

string notNull = "Hello";
string? nullable = default;
notNull = nullable!; // null forgiveness

问题

有什么原因不总是在 *.csproj 文件中启用不可为空性？

你有清单吗？比如，“不要<Nullable>enable</Nullable> if ... a)... b)... c)...”？

我能想到的

我能想到的唯一原因是与现有代码的向后兼容性。含义：打开该功能并修复所有编译器错误并调整代码可能太耗时且因此昂贵；也许也容易出错。

我已经用谷歌搜索了，但没有找到任何其他原因：when not to use non-nullable refernce types in c# - Google Search

文档

• 微软文档 → Nullable reference types
• 这篇博文给出了很多说明性的代码示例：Containing Null with C# 8 Nullable References, Frank A. Krueger

附言

请让我知道 Stack Overflow 是否是问这个问题的错误地点，以及哪个 Stack Exchange 网站更适合。

我认为 Stack Exchange 可能是正确的位置，因为 What topics can I ask about here?

• “软件开发独有的实用、可回答的问题”

Answer 1

这是因为语义空检查器没有（也不能）涵盖断言变量已从非空值分配的所有条件，并且需要许多额外的标记来帮助空检查器，如系列属性，甚至不足以让一切看起来都很好。

这是一个不完整的列表：

• 当一个方法的返回值依赖的参数复杂且无法用NotNullWhen系列属性描述时，即使可以断言不为null，也应该标记为可空。

• null 检查器只能将类的构造函数视为唯一的初始化时机，这意味着其生命周期由库/框架拥有和管理的某些对象（反序列化实体、虚拟演员、剃须刀组件等）应该是声明所有字段都标记为可空，即使假定某些库定义的初始化方法（分配所有必需的不可空值）在任何其他方法之前被调用。

• 当流检查器无法断言局部变量的可空状态时，该局部变量通过var 关键字推断为始终可以为空，或者从某些没有或不能准确标记可空性的代码返回的值，它是在使用前被视为可空以强制执行空检查或!，即使程序员清楚地知道它不能为空。

是的，您可以在任何地方使用! 或[AllowNull] 系列来禁用空值检查器，但是为什么不直接禁用整个空值检查机制呢？因此，可为空的特性将毫无意义。

可空引用类型特性只适用于具有非常基本或琐碎逻辑的项目。只要它的花费超过它的帮助，不启用它是合理的。