8.3 类型等价、兼容、强制转换与显式转换
当语言里的类型越来越多时，编译器要回答的问题就不再只是“这个表达式是什么类型”，还包括“一个类型什么时候能拿来当另一个类型用”。这就是类型等价、类型兼容、隐式强制转换（coercion） 和 显式类型转换（cast） 要解决的事。
这几个词经常一起出现，但绝不能混成一个概念。
| 概念 | 它在问什么 | 典型例子 |
|---|---|---|
| 等价（equivalence） | 这两个类型是否被视为同一个类型？ | 两个 int 别名 |
| 兼容（compatibility） | 一个类型的值能否出现在另一个类型期待的位置？ | int 用在 float 位置 |
| 隐式强制转换 | 编译器能否悄悄插入转换？ | int -> float 提升 |
| 显式类型转换 | 程序员能否在源码中强行写出这一步转换？ | int(3.9) |
等价通常比兼容更强
两个类型可以不等价，却仍然兼容。最常见的例子就是 int 到 float。语言也许允许它，是因为这种加宽（widening）在多数场景里风险低、语义直观，但这并不意味着 int 和 float 本来就是同一个类型。
把这两个概念分开，诊断会更清楚：
- “不等价”表示语言认为它们根本不是同一种类型。
- “不兼容”表示当前上下文不允许这样用。
- “需要显式类型转换”表示语言觉得这一步有风险，不能默默替你做。
隐式强制转换必须非常克制
一旦允许隐式强制转换，语言就在做一个很强的承诺：编译器可以在你没写出来的情况下替你改写程序，而且这种改写应该足够自然、不会让人吃惊。所以它只能用在很保守的地方。
比较适合做隐式强制转换的转换通常同时满足：
- 常见，
- 风险低，
- 语义直观，
- 不容易掩盖缺陷（bug）。
这也是为什么很多语言容忍 int -> float，却不容忍 float -> int 的静默缩窄。后者会丢精度、截断信息，读代码的人也很难从表面看出程序到底改了什么。
对用户自定义命名类型更应如此。如果 UserId 能自动变成 int，那编译器就把本来想保护的语义边界直接拆掉了。
显式类型转换的作用是把风险写出来
显式类型转换不是“证明这一步一定安全”，而是程序员在源码里明确表态：这一步不是普通转换，我知道它有风险，但我愿意承担。
这种风险可以有很多来源：
| 转换类型 | 主要风险 |
|---|---|
| 数值缩窄 | 精度或范围丢失 |
| 命名类型逃逸到基础类型 | 语义边界被抹掉 |
| 重解释（reinterpret）风格转换 | 绕过类型系统原本的保证 |
所以在工程上，显式类型转换与隐式强制转换应被当成两种完全不同的东西看待。隐式强制转换是语言层面的统一政策；显式类型转换则是程序员在某个具体位置申请“例外”。
一条很实用的判断规则
如果一个转换可能改变程序含义、丢失信息，或者越过领域边界，那就应该要求显式写出来，甚至直接禁止。
一个例子
设想语言里有：
type UserId = int
type Meters = float即使它们底层都能表示成数字，编译器仍然完全可以拒绝把 UserId 赋给 Meters，反之亦然。这里防守的不是存储位宽，而是语义：类型检查器在阻止“身份值”和“长度值”混成一类。