Scala中使用@uncheckedVariance强制抽象类型协变的风险探讨

我最近在研究Scala里集合类型的协变设计，尤其是抽象类型在方差处理上的应用——虽然方差（variance）的基础概念在诸多资料中已有详尽阐述，但针对抽象类型的相关讨论却很少。为了搞清楚集合类型的设计逻辑，我写了几段测试代码，过程中遇到了一些困惑，也做了一些尝试，现在来梳理一下：

初始尝试：抽象类型等式定义的局限 #

首先我定义了基础的集合操作 trait，然后尝试通过抽象类型CC来表示集合的映射结果类型，但很快发现用等式定义抽象类型会导致继承时的编译问题：

trait CollectionOps[+A, +C] { this: C =>
  type CC[B] <: BasicColl[B] // 不变位置
  def filter(f: A => Boolean): C
  def map[B](f: A => B): CC[B] // CC处于协变位置，但通过抽象类型声明为不变
}

trait BasicColl[+A] extends CollectionOps[A, BasicColl[A]] {
  type CC[B] = BasicColl[B] // 此处为问题所在，使用了等式定义
  // 若改为不等式：type CC[B] <: BasicColl[B]
}

// 因上述等式定义及CC的不变性，无法编译
trait BasicColl2[+A] extends BasicColl[A] with CollectionOps[A, BasicColl2[A]] {
  type CC[B] = BasicColl2[B]
  // 若使用之前的不等式定义，则可写为：type CC[B] <: BasicColl2[B]
}

接下来我测试了两种抽象类型定义的效果：

等式定义的测试 #

trait Test_With_Abstract_Type_Equality {
  // 仅存在BasicColl
  def coll1: BasicColl[Int]
  // 因CC与BasicColl的等式定义，可获得精确类型
  def mapped: BasicColl[Double] = coll1.map(_.toDouble)
  // 但无法实现特化继承
}

不等式定义的测试 #

trait Test_With_Abstract_Type_Inequality {
  def coll1: BasicColl[Int]
  // 因CC与BasicColl的不等式定义，得到抽象类型
  def mappedWithAbstractTypeDef: BasicColl[Int]#CC[Double] = coll1.map(_.toDouble)
  // BasicColl2可以存在
  def coll2: BasicColl2[Int]
  // 因CC与BasicColl2的不等式定义，得到抽象类型
  def mappedWithAbstractTypeDef2: BasicColl2[Int]#CC[Double] = coll2.map(_.toDouble)
}

Scala标准库的解决方案 #

我注意到Scala标准库并没有使用抽象类型，而是直接采用协变参数化类型CC，比如：

trait IterableOnceOps[+A, +CC[_], +C]

这种方式的优势在于便于trait混合，但将高阶类型用于参数层面会限制对多参数类的扩展；而抽象类型虽然允许扩展更复杂的类，但代价是映射操作的返回值会是抽象类型。

我的改写尝试与核心疑问 #

为了兼顾抽象类型的扩展性和精确的返回类型，我做了如下改写，但不确定其中@uncheckedVariance的使用是否存在风险：

// 重定义
trait CollectionOps[+A, +C] { this: C =>
  type CC[B] <: BasicColl[B] // 不变位置
  def filter(f: A => Boolean): C
  def map[B](f: A => B): CC[B] // CC处于协变位置
}

// 重定义
trait BasicColl[+A] extends CollectionOps[A, BasicColl[A]]

trait CollectionOpsLocked1[+A, +CCC[B] <: BasicColl[B], +C] extends CollectionOps[A, C] { this: C =>
  type CC[B] = CCC[B] @uncheckedVariance // 我的疑问点
  // 若仅在协变位置使用CC，是否存在风险？
}

trait BasicColl2[+A] extends BasicColl[A] with CollectionOpsLocked1[A, BasicColl2, BasicColl2[A]]

trait BasicColl3[+A] extends BasicColl2[A] with CollectionOpsLocked1[A, BasicColl3, BasicColl3[A]]

trait Test {
  def coll1: BasicColl[Int]
  def mappedWithAbstractTypeDef: BasicColl[Int]#CC[Double] = coll1.map(_.toDouble)
  // BasicColl2可以存在
  def coll2: BasicColl2[Int]
  def mapped2: BasicColl2[Double] = coll2.map(_.toDouble)
  // BasicColl3可以存在
  def coll3: BasicColl3[Int]
  def mapped3: BasicColl3[Double] = coll3.map(_.toDouble)
}

核心问题：在协变/逆变合法的位置使用@uncheckedVariance是否存在风险？ #

简单来说，@uncheckedVariance是用来绕过Scala编译器的方差检查，把类型安全的责任完全交给开发者。如果能严格保证CC只在协变合法的位置（比如方法返回值这类输出位置）被使用，那么这种用法的风险是可控的——因为协变类型在输出位置本来就是安全的，编译器的报错只是因为抽象类型的声明位置导致的误判，用@uncheckedVariance相当于告诉编译器“我确认这里的用法是安全的”。

但需要警惕几个潜在风险：

• 误用风险：如果后续代码不小心把CC放到了逆变或不变的危险位置（比如方法参数、可变字段），编译器不会再进行检查，这时候很可能出现类型不安全的情况，比如将子类集合当作父类集合传入，导致运行时错误。
• 维护成本：@uncheckedVariance会降低代码的可读性，其他开发者需要额外注意这里的类型安全逻辑，增加了维护的复杂度。
• 修改隐患：如果后续修改了CC的使用场景，忘记同步验证@uncheckedVariance的合理性，很容易引入隐蔽的bug。

总结：只要能严格约束CC的使用范围在协变安全的位置，这种写法是可行的，但需要谨慎维护，确保不会违反方差规则。

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