8.4 重载与类型推断基础

类型系统里最常见、也最容易让编译器变复杂的两个能力，就是重载和类型推断。它们都能减少源码里的重复，但也都会逼着编译器在“信息还不完整”的情况下做出合理判断。

重载要回答的是：“同一个名字有多个定义，这里到底该选哪一个？” 类型推断要回答的是：“程序没把类型全写出来，那缺掉的类型到底被哪些约束所决定？”

这两件事有一个共同要求：结果必须可解释。靠隐蔽的决胜规则（tie-breaker）或“神秘直觉”得出的答案，迟早会变成维护问题。

重载解析需要明确的排序规则

设想语言里有：

print(int)
print(float)

当用户写 print(3) 时，解析器应该优先选精确匹配的 print(int)。当用户写 print(3.0) 时，则应选 print(float)。如果多个候选同样合适，最合理的做法通常不是静默挑一个，而是直接报二义性错误。

这背后其实就是一套简单的优先顺序：

类型推断本质上是在解约束

很多人说类型推断是编译器“猜类型”，这个说法并不准确。更好的图景是：编译器先创建类型变量，再收集约束，最后统一这些约束。

例如：

let x = 1

一开始可以把它看成 x : ?T。字面量告诉编译器 1 : int。赋值关系则给出约束 ?T = int。统一完成后，就得到 x : int。

这套思路可以自然扩展：

• 形参引入未知量，

• 返回表达式约束未知量，

• 调用点实例化未知量，

• 复合类型构造继续把约束往外传播。

推断永远有边界

即使类型推断很强的语言，也往往会在某些位置要求你显式写出类型。常见原因包括：

• 递归定义靠自身不足以形成足够约束，

• 对外公开的 API 需要稳定契约，

• 重载解析会因为信息不足而变得二义，

• 或者推断结果虽然正确，但对人类读者来说太难看懂。

这里有一个很重要的工程结论：推断和注解不是对立面。很多时候，注解既是给编译器看的，也是给人看的。

一个对比例子

比较下面两个声明：

let id = (a) => a
let parseId: (string) -> UserId = ...

前者很适合推断，因为它的局部约束简单清楚。后者则很适合保留显式注解，因为它定义了一个其他模块会依赖的边界。好的语言设计不是追求“全都能推断”，而是知道哪里靠推断更自然，哪里写出来反而更清楚。