可检验属性。静态类型系统可以保证消除某些运行时的错误。例如可以保证：布尔型不会与
整数型相加；私有变量不会从类的外部被访问；用正确数量的参数调用了函数；字符串集只能加入
字符串。
不过当前的静态类型系统还不能查到其他类型的错误。比方说，通常查不到无法终结的函数，数组
越界，或除零错误。同样也查不到你的程序不符合规格说明书（假设有这么一份规格说明书）。因
此有些人认为静态类型系统不太有用而忽视它。批评说既然这种类型系统只能发现简单错误，而单
元测试能提供更广泛的覆盖，那又为何自寻烦恼使用静态类型呢？我们认为这种说法不正确。尽管
静态类型系统确实不能替代单元测试，但是却能减少用来测试这些属性的单元测试的数量。同样，
单元测试也不能替代静态类型。总而言之，如Edsger Dijkstra 所说，测试只能证明存在错误，而非
不存在。14因此，静态类型能给的保证或许很简单，但这些保证无论多少测试都给不了。
安全的重构。静态类型系统提供了让你具有高度信心去变动代码基础的安全网。试想一个给
方法新增参数的重构实例。在静态类型语言中，你可以完成修改，重编译你的系统并简单地修改所
有引起类型错误的代码行。一旦完成了这些，你可以确信已经发现了所有需要修改的地方。这种信
心对于其他的简单重构，如改变方法名或把方法从一个类移到另一个，都会有效。静态类型检查会
在所有的例子中提供足够的确信，表明新系统和旧系统可以一样的工作。
文档。静态类型是被编译器检查过正确性的程序文档。不像普通的注释，类型标注永远都不
会过期（至少如果包含它的源文件近期刚刚通过编译就不会）。更进一步说，编译器和集成开发环
境可以利用类型标注提供更好的上下文帮助。举例来说，集成开发环境可以通过判定选中表达式的
静态类型，找到类型的所有成员，并全部显示出来。

def f(x: String) = ...
知道f 的变量应该是String 是有用的。另一方面，以下例子中两个标注至少有一个是讨厌的：
val x: HashMap[Int, String] = new HashMap[Int, String]()
很明显，x 是以Int 为键，String 为值的HashMap 这句话说一遍就够了；同样的句子没必要重
复两遍。
Scala 有非常精于此道的类型推断系统，能让你省略几乎所有的通常被认为是讨厌的类型信息。前面
的例子可以改写成以下两种方式：
val x = new HashMap[Int, String]()
val x: Map[Int, String] = new HashMap()
Scala 里的类型推断不止于此。实际上，就算用户代码丝毫没有显式类型也不稀奇。因此，Scala 程
序经常看上去有点像是动态类型脚本语言写出来的程序。尤其在客户应用代码中作为预编译代码库
控件的胶水代码时，表现得更为显著。而对于库控件来说不是这么回事，因为它们常常用到相当精
妙的类型去使其适于灵活使用的模式。这是由代码的实际情况决定的。毕竟，构成可重用控件接口
的成员的类型符号应该是显式给出的，因为它们构成了控件和它的使用者间契约的重要部分。