首页 > 解决方案 > 是否有任何理由不总是使用 C# 8.0 的不可为空的引用类型?

问题描述

语境

C# 8.0 具有不可为空引用类型的这一特性。

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

问题

有什么原因不能始终在 *.csproj 文件中启用不可为空性?

你有清单吗?比如,“<Nullable>enable</Nullable>如果……a)……b)……c)……”?

我能想到的

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

我已经用谷歌搜索但没有找到任何其他原因:何时不在 c# 中使用不可为空的引用类型 - Google 搜索

文档

附言

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

我认为 Stack Exchange 可能是正确的位置,因为我可以在这里询问哪些主题?

标签: c#-8.0non-nullable

解决方案


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

这是一个不完整的列表:

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

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

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

是的,您可以在任何地方使用!or [AllowNull]series 来禁用空检查器,但为什么不直接禁用整个空检查机制呢?因此,可为空的特征将毫无意义。

可空引用类型功能仅适用于具有非常基本或琐碎逻辑的项目。只要它花费的多于它的帮助,不启用它是合理的。


推荐阅读