c# – 为什么Null对那些喜欢类型安全的人来说并不是类型安全的

I’m not really into type-safety as a concept

也许你应该.

for code to scale well,be reusable,be robust etc… it needs to be type safe.

我不认为它需要是类型安全的,尽管它确实有帮助.很多人用C编写代码,这种语言具有相对较弱的类型安全性(因为指针可以转换为任意整数和从任意整数转换).然而,C也是一种语言,旨在通过封装在类中的健壮代码来鼓励代码重用.

另外,不要将静态类型检查与类型安全混淆.有人会争辩说,动态检查的语言都是“类型安全的”;他们只是在运行时而不是编译时进行类型系统验证.

Langueges like C# take type-safety seriously

确实.

generics in C# are considerably more typesafe than C++ templates.

我没有看到任何证据证明这种说法.对泛型的类型检查与对模板的类型检查不同,但两者都是类型检查.根本区别在于泛型假定满足约束的任何类型都可以是类型参数,因此需要程序为任何可能的类型参数传递静态类型检查.另一方面,模板只需要您实际用于传递静态类型检查的类型参数.

Even ArrayList which is considered not as typesafe as List<T> being that it is a List<object> is much more typesafe than for example a List<dynamic>,which I think should be possible but is certainly obscure.

好吧,动态是一个有趣的案例.就像我之前说的那样,动态基本上意味着“将这个东西的类型检查移动到运行时”.

I wonder why,again using C# as an example there is still null. I can see how in some respects it is faster than ensuring everything is constructed by default but isn’t it a huge type-safety issue

你提出这个问题是对的; nulls确实在类型检查器中引发了一个难题.人们希望静态类型语言是“内存安全的” – 以确保没有无效的位模式进入使用特定类型注释的变量. C#(在不安全子集之外)实现了这个目标,除了全零空引用位模式在用引用类型注释的变量中总是合法的,即使该位模式指的是没有有效对象.

你当然可以提出没有空引用的语言,并且是静态类型检查的; Haskell就是一个很好的例子.为什么不在C#中做同样的事情呢？

历史原因.尽管存在危险,但空引用非常有用,C#源于允许空引用的编程语言的悠久传统.

如果我们从第一天开始就将可空性纳入框架,我个人会更喜欢它,这样你就可以拥有可空或不可空的值类型,以及可空或不可空的引用类型.请记住,下次从头开始设计类型系统时.

also requires extra time-consuming runtime checking for the computer to throw null exceptions and the such

这实际上并没有那么糟糕.通常实现这些东西的方式是包含空指针的虚拟内存页面被标记为不可读,可写或可执行.尝试这样做会导致硬件引发异常.即使在您必须进行空检查的情况下,将寄存器与零进行比较也非常快.

有更糟糕的问题.例如,在您无法静态类型检查程序是否保证仅访问数组的有效索引的意义上,数组也不是“类型安全”. CLR做了很多工作来确保每个数组访问都是有效的.

不安全的阵列协方差也存在问题;这是类型系统的真正问题.每次将更多派生类型的元素写入其基类型数组时,我们都必须进行类型检查.这是我对CLR“最差特征”的候选人.