Scala 2与Scala 3类成员类型推断差异及相关问题咨询

问题场景示例 #

先看这段核心代码：

class A           {              }
class B extends A { def m = true }

trait X           { def obj : A     }
class Y extends X { def obj = new B }

val y = new Y
y.obj.m // 在Scala2中可编译，在Scala3中无法编译。

核心差异点 #

y.obj的类型在两个版本的Scala中表现截然不同：

• 在Scala2中，y.obj被推断为B类型，因此调用m方法可以正常编译
• 在Scala3中，y.obj的类型被限定为父特质X中声明的A类型，导致y.obj.m编译失败

这是因为Scala3中，父类/特质的抽象成员类型声明优先级高于子类的窄类型推断。只有以下两种情况，y.obj的类型才会被推断为B：

// 情况1：不继承X，成员无父类声明约束
class Y { def obj     = new B }
// 情况2：显式指定子类成员的具体类型
class Y extends X { def obj : B = new B }

当结合transparent inline方法传递细化类型信息时，这个问题会更突出，示例代码如下：

class A
class B extends A:
  def m = true

transparent inline def choose(b: Boolean): A =
  if b then new A else new B

class X:
  def obj1 : A
  def obj2 : A
  def obj3 : A

class Y extends X:
  def obj1     = choose(true)  // 类型为A
  def obj2     = choose(false) // 类型为A（受X的obj2声明约束）
  def obj3 : B = choose(false) // 类型为B（显式指定类型）
  def obj4     = choose(false) // 类型为B（无父类声明约束，自动推断）

val y = new Y
y.obj1.m // 编译错误     符合预期
y.obj2.m // 编译错误   不符合预期
y.obj3.m // 可编译          符合预期
y.obj4.m // 可编译          符合预期

待解答的问题 #

1. Scala2与Scala3之间的这种差异是否是预期的？
2. 该设计的意图是什么？
3. 有无可行的解决方案？

解答 #

1. 差异是否是预期的？ #

是预期行为，这是Scala3在类型系统设计上的明确变更，属于Scala2迁移到Scala3的已知不兼容点之一。

2. 设计意图是什么？ #

这个变更的核心目标是提升类型系统的一致性和可预测性：

• Scala2中，子类实现父类抽象成员时，编译器会隐式“放大”推断类型（使用更具体的子类类型），但这种行为在复杂继承、特质混合场景下容易导致类型推断结果不稳定，引发难以排查的类型问题。
• Scala3选择严格遵循父类声明的类型作为成员的对外可见类型，除非子类显式指定更具体的兼容类型。这样代码的类型行为更符合直观预期——父类声明的类型就是该成员对外暴露的接口类型，避免了隐式类型放大带来的意外。

3. 可行的解决方案 #

针对该问题，有几种实用的解决方式：

• 显式指定子类成员类型：在子类实现父类抽象成员时，明确标注更具体的类型（需满足父类类型的子类型约束），比如def obj: B = new B，让编译器认可该具体类型。
• 使用override关键字强化意图：Scala3中实现抽象成员无需override，但加上override def obj: B = new B可以更清晰地表明类型细化的意图，同时确保类型被正确识别。
• 调整父类设计：如果场景允许，可将父类的抽象成员改为抽象类型成员或使用泛型保留类型信息，示例如下：

  trait X[T <: A] { def obj: T }
  class Y extends X[B] { def obj = new B }
  

• transparent inline场景的处理：必须显式指定子类成员的具体类型，才能让transparent inline带来的类型细化效果对外可见，否则父类的类型声明会覆盖推断出的具体类型。

内容的提问来源于stack exchange，提问作者Jean-Jacques Lecler