Question

我在应用于def和val时发现了Scala类型推断的差异。

使用def，我可以定义一个抽象的nullary方法const，返回类型为Int => Int的值。在使用函数文字实现const时，我不需要提供参数类型，因为它可以由编译器推断：

trait D {
  def const: Int => Int
}
object D extends D {
  def const = i => i + 1
}

这很好。（在缺点方面，正在为D.const的每次访问创建一个新的函数实例。）

现在考虑使用val：

的类似结构

trait V {
  val const: Int => Int
}
object V extends V {
  val const = i => i + 1
}

这将无法编译，

失败

error: missing parameter type
   val const = i => i + 1
               ^

为什么？

Answer 1

如果使用-Xprint all选项构建此代码，您将看到：

abstract trait V extends scala.AnyRef {   
<stable> <accessor> def const: Int => Int
};

final object V extends java.lang.Object with V with ScalaObject {

def this(): object V = {
  V.super.this();
  ()
};

private[this] val const: <error> => <error> = ((i: <error>) => i.+(1));
<stable> <accessor> def const: <error> => <error> = V.this.const
}

因此，在创建私有val和访问器时会发生错误。在创建访问器def const之前，编译器尝试评估受val const影响的值。

如果查看trait中定义的val const，您会看到私有val的创建被禁用，因为它只是def const访问器的定义。

我认为具有先前定义（在特征或超类中）的推理类型仅在他尝试创建访问器时发生，而不是用于评估值。

对于最后一个def const，该类型仅基于private [this] val const类型：error =＆gt;错误

Answer 2

从Scala 2.9.1开始，这是“as speced”。引用来自SI-2742的Martin Odersky：

对于方法，继承抽象方法中的返回类型被视为右侧的预期类型。对于价值观，没有这样的规则。所以这就是规格增强请求，正如我所看到的那样。

这张票是低优先级的，自2009年底第一次讨论以来一直保持不变，所以它似乎不太可能很快改变。

Scala中`def`和`val`的不同类型推断

2 个答案: