这是一个简单的例子:
trait Base {
type Out
def v: Out
}
object Base {
type Aux[T] = Base { type Out = T }
class ForH() extends Base {
type Out = HNil
override def v: Out = HNil
}
object ForH extends ForH
}
class TypeClass[B]
trait TypeClassLevel1 {
def summon[B](b: B)(implicit ev: TypeClass[B]): TypeClass[B] = ev
}
object TypeClass extends TypeClassLevel1 {
implicit def t1: TypeClass[Base.Aux[HNil]] = new TypeClass[Base.Aux[HNil]]
implicit def t2: TypeClass[Int] = new TypeClass[Int]
}
it("No Aux") {
val v = 2
TypeClass.summon(v) // works
}
it("Aux") {
val v = new Base.ForH()
TypeClass.summon(v) // oops
TypeClass.summon(Base.ForH) // oops
val v2 = new Base.ForH(): Base.Aux[HNil]
TypeClass.summon(v2) // works!
}
对象 Base/ForH 显然有一个稳定的路径,这消除了编译器无法解析 type 的可能性ForH.Out
。
困扰我的不是编译器多么无能为力ForH <:< Aux[HNil]
,而是通过简单的类型向上转换(最后两行)来修补它是多么容易。恕我直言,这两个特性(类型 lambda 和类型类)都是函数式编程的重要方面,为什么它们不能同时协同工作?
如果您熟悉编译器设计,我会有一个额外的问题:如何改进类型类搜索算法以实现它?非常感谢您的意见。
更新 1:已经提出了一个特定的修复,但我在尝试概括它时遇到了另一个问题,请参阅In scala, how to make type class working for Aux 模式?-详细信息第 2 部分