在scala 2中,宏或任何语言特性都可以用来重写所有子类中的抽象类型具体化机制吗?scala 3怎么样?

9gm1akwq  于 2021-07-13  发布在  Java
关注(0)|答案(0)|浏览(258)

赏金7天后到期。回答此问题可获得+150声望奖励。tribbloid正在寻找一个可靠来源的答案**:

理想情况下,您的答案可以以一个开源项目为例进行演示
在scala 2中,宏是严格局部的,并且在定义类时只执行一次。当与抽象类型相结合时,此功能似乎特别弱,因为将抽象类型转换为具体类型的过程通常会绕过宏并使用自己的基本规则。
下面的测试代码中有一个简单的例子演示了一个反直觉的结果:

trait BB {

    def ttag = implicitly[TypeTag[this.type]]
  }

  case class AA() extends BB

  it("can TypeTag") {

    val kk = AA()

    TypeViz(kk.ttag).peek // this function visualise the full type tree of the type tag
  }

如果执行,kk的类型为:

-+ BB.this.type
 !-+ InfoCTSpec.this.BB
   !-+ Object
     !-- Any

哦,aa类型被完全忽略了,因为 implicitly[TypeTag[this.type]] 由一个内置的隐式宏支持,它只在定义bb时执行一次,而不是在定义aa并具体化实际值时执行 kk.this.type . 我发现它非常笨拙,并且容易由于运行时类型擦除而导致一些其他特性(例如模式匹配、类型lambda)降级。
我想写一个语言扩展,例如make TypeTag[this.type] aa的一个子类型,没有引入运行时开销和范围外的上下文对象(因此,没有隐式)。我怎样才能用最少的黑客攻击做到这一点?我对编译器扩展和宏之类的硬核解决方案持开放态度,但一个优雅的解决方案可以顺利地转移到scala3/dotty显然是首选。
p、 看起来dotty的“inline/compiletime”特性已经部分实现了我的设想。这是正确的印象吗?

暂无答案!

目前还没有任何答案,快来回答吧!

相关问题