Scala 2.13中为何可为抽象类型获取非限定TypeTag？

import scala.reflect.api.Universe

object UnqualifiedTypeTag {

  val RuntimeUniverse = scala.reflect.runtime.universe

  trait HasUniverse {

    val universe: Universe with Singleton

    def uType: RuntimeUniverse.TypeTag[universe.type] = implicitly
  }

  object HasRuntime extends HasUniverse {

    override val universe: RuntimeUniverse.type = RuntimeUniverse
  }

  def main(args: Array[String]): Unit = {
    println(HasRuntime.uType)
  }
}

问题背景 #

理想情况下，这段代码要么生成TypeTag[HasRuntime.universe.type]，要么直接编译失败——因为implicitly在调用点无法知晓具体的universe.type实例（与之相对的是，WeakTypeTag[universe.type]能正常工作）。

但实际运行结果却生成了TypeTag[HasUniverse.this.universe.type]，这明显违背了TypeTag的常见约定：

• 与WeakTypeTag不同，TypeTag不应从抽象类型初始化
• TypeTag应该始终能被擦除为对应的Class

核心疑问 #

1. 这种设计的目的是什么？
2. TypeTag到底提供了何种契约？
3. 这是否是Scala 2.11之后ClassTag本该被取代却至今仍被保留的原因？

解答 #

1. 该设计的目的：兼容抽象语境下的反射需求 #

Scala的TypeTag机制并非完全拒绝抽象类型的初始化，而是在编译期尽可能保留类型的路径依赖信息。在HasUniverse trait中，universe是一个抽象的单例类型，编译器为它生成的TypeTag实际上是一个路径依赖的抽象TypeTag——它记录了类型的相对路径（HasUniverse.this.universe.type），而非具体的单例类型。这种设计是为了支持在抽象特质或类中预先定义反射相关的接口，让子类在实现时可以复用这些逻辑，同时保留类型的上下文信息。

2. TypeTag的契约 #

TypeTag的核心契约是在编译期捕获完整的类型信息，包括路径依赖、泛型参数等细化类型，并在运行期提供对这些信息的访问能力。但需要明确：

• 它并非强制要求必须对应一个可直接擦除的具体Class，而是允许存在抽象的路径依赖类型——这是因为Scala的类型系统本身支持路径依赖，TypeTag需要适配这一特性。
• 与WeakTypeTag的区别在于：TypeTag会保留完整的类型结构（包括具体化的单例类型、泛型实参等），而WeakTypeTag仅保留“弱”类型信息（可以是抽象的、未具体化的）。但在抽象语境下，编译器无法生成具体化的TypeTag，只能退而求其次生成路径依赖的抽象TypeTag，这是对类型系统表达能力的妥协。

3. ClassTag保留至今的原因 #

这和上述行为有直接关联：TypeTag虽然强大，但它的路径依赖特性和对抽象类型的兼容导致它无法完全替代ClassTag的核心功能——直接获取类型的擦除Class实例。ClassTag的契约是明确的：它只关注类型的擦除结果，不处理路径依赖或泛型的细化信息，因此在需要直接操作Class对象（比如数组创建、反射实例化）的场景下，ClassTag更加可靠和直接。

此外，ClassTag的API更轻量化，在很多只需要擦除类型的场景下，使用ClassTag比TypeTag更高效，也避免了路径依赖带来的复杂性。因此Scala官方并没有移除ClassTag，而是让两者各司其职：TypeTag用于需要完整类型信息的反射场景，ClassTag用于仅需擦除类型的操作场景。

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