Scala中Int是否为List[Int]的超类型？结合fold方法的类型疑问

你之前的误判本质是完全搞混了Scala集合泛型的参数语义，错把fold方法的调用接收者的整体类型，绑定成了签名里的类型参数A。这个错位自然会导出“Int是List[Int]超类型”的荒谬结论，实际上从代码能正常编译运行这个事实，就可以直接推翻这个假设。

先回到fold方法的真实签名定义，它是Scala通用集合体系里为所有可迭代容器定义的方法：

fold[A1 >: A](z: A1)(op: (A1, A1) => A1): A1

这里的类型参数语义是非常明确的：

• 签名里的A，是调用这个fold方法的集合自身携带的元素类型，不是集合本身的类型。对你例子里的list: List[Int]来说，这里的A会被直接绑定为Int，根本不是List[Int]。
• 签名里的A1 >: A，是对折叠结果类型的约束：要求你传入的初始值类型A1，必须是元素类型A的超类型（当然类型本身自己也是自己的超类型，完全满足语法约束）。

放到你的求和示例里，整个类型推导的流程是：

• 集合是List[Int]，绑定的A = Int
• 你传入的初始值是0，类型是Int
• 编译器校验发现Int满足A1 >: Int的约束，就直接把A1绑定为Int，整个过程和List[Int]这个集合类型本身没有任何继承关系层面的关联。

• 很多技术博客在演示fold用法的时候，跳过了泛型绑定的细节，直接上来就举求和的例子，很容易让初学者把“集合装的元素”和“集合本身”的泛型语义搞混。
• 你可以顺着逻辑反推：如果真的像之前误判的那样，A是整个List[Int]的类型，那A1作为它的超类型，就不可能是Int——毕竟Int和List[Int]分属完全不同的类型层级，根本不存在继承关系，编译器这时候肯定会报类型不匹配的错误，但你的示例代码是可以正常编译、正常得到sum=15的结果的，这反过来就证明之前的类型绑定是错的。

这个超类型约束本来的设计目的，就是支持折叠过程中累加器类型的范围比元素类型更大的场景：

• 比如你有一个List[Cat]类型的集合，每个元素都是猫的实例，你完全可以用一个Animal类型的初始值做累加器，在折叠过程中把所有猫的共性属性提取出来，累加到这个动物类型的累加器里。这时候A是Cat，A1是Animal，刚好满足Animal >: Cat的约束——整个过程从来没有把集合本身的类型代入过泛型参数。

内容的提问来源于stack exchange，提问作者egimaben