面向对象的编程语言中的引用是否应该默认为不可为空？

Question

空指针被描述为" 十亿美元的错误 ".某些语言具有无法分配空值的引用类型.

我想知道在设计一种新的面向对象语言时是否应该使用默认行为来防止被赋值为null.然后可以使用特殊版本来覆盖此行为.例如:

MyClass notNullable = new MyClass();
notNullable = null; // Error!
// a la C#, where "T?" means "Nullable<T>"
MyClass? nullable = new MyClass();
nullable = null; // Allowed

所以我的问题是,有没有理由不在新的编程语言中这样做？

编辑:

我想补充一点,我博客上的最新评论指出,当在数组中使用时,非可空类型有一个特殊的问题.我还要感谢大家的有益见解.这非常有帮助,对不起,我只能选择一个答案.

Answer 1

默认情况下,我看到非可空引用类型的主要障碍是编程社区的某些部分更喜欢create-set-use模式:

x = new Foo()
x.Prop <- someInitValue
x.DoSomething()

重载构造函数:

x = new Foo(someInitValue)
x.DoSomething()

这使得API设计者在实例变量的初始值方面处于绑定状态,否则可能为null.

当然,就像'null'本身一样,create-set-use模式本身会创建许多无意义的对象状态并阻止有用的不变量,因此摆脱它实际上是一种祝福,而不是一种诅咒.然而,它确实以许多人不熟悉的方式影响了一些API设计,所以它不是轻易做的事情.

但总的来说,是的,如果有一场大灾难摧毁了所有现有的语言和编译器,人们只能希望,当我们重建时,我们不会重复这个特殊的错误.可空性是例外,不是规则!