为什么Scala编译器不允许使用默认参数重载方法？

尽管在某些情况下，这种方法重载可能会变得模棱两可，但为什么编译器却不允许在编译时和运行时都模棱两可的代码呢？

例：

// This fails:
def foo(a: String)(b: Int = 42) = a + b
def foo(a: Int)   (b: Int = 42) = a + b

// This fails, too. Even if there is no position in the argument list,
// where the types are the same.
def foo(a: Int)   (b: Int = 42) = a + b
def foo(a: String)(b: String = "Foo") = a + b

// This is OK:
def foo(a: String)(b: Int) = a + b
def foo(a: Int)   (b: Int = 42) = a + b    

// Even this is OK.
def foo(a: Int)(b: Int) = a + b
def foo(a: Int)(b: String = "Foo") = a + b

val bar = foo(42)_ // This complains obviously ...

有什么理由不能放宽这些限制？

特别是在将重载的Java代码转换为Scala时，默认参数非常重要，并且在用规范/编译器施加了任意限制的一个Scala方法替换了大量Java方法后，很难找到默认参数。

我想引用Lukas Rytz（从这里开始）：

原因是我们希望为返回默认参数的生成方法确定性的命名方案。如果你写

def f(a: Int = 1)

编译器生成

def f$default$1 = 1

如果您在相同的参数位置上有两个具有默认值的重载，我们将需要不同的命名方案。但是我们希望在多个编译器运行中保持生成的字节码稳定。

将来的Scala版本的解决方案可能是将非默认参数的类型名称（方法开头的名称，消除了重载版本的歧义）合并到命名模式中，例如，在这种情况下：

def foo(a: String)(b: Int = 42) = a + b
def foo(a: Int)   (b: Int = 42) = a + b

就像这样：

def foo$String$default$2 = 42
def foo$Int$default$2 = 42

有人愿意写SIP提案吗？

对于重载分辨率与默认参数的交互，很难获得一个可读且精确的规范。当然，对于许多个别情况，例如此处介绍的情况，很容易说出应该发生的情况。但这还不够。我们需要一个确定所有可能的极端情况的规范。重载分辨率已经很难指定。在混合中添加默认参数将使其更加困难。这就是为什么我们选择将两者分开。

我无法回答您的问题，但这是一种解决方法：

implicit def left2Either[A,B](a:A):Either[A,B] = Left(a)
implicit def right2Either[A,B](b:B):Either[A,B] = Right(b)

def foo(a: Either[Int, String], b: Int = 42) = a match {
  case Left(i) => i + b
  case Right(s) => s + b
}

如果您有两个很长的arg列表，而它们之间只有一个arg，则可能会遇到麻烦...

对我有用的是重新定义（Java风格的）重载方法。

def foo(a: Int, b: Int) = a + b
def foo(a: Int, b: String) = a + b
def foo(a: Int) = a + "42"
def foo(a: String) = a + "42"

这样可以确保编译器根据当前参数所需的分辨率。

这是@Landei答案的概括：

您真正想要的是：

def pretty(tree: Tree, showFields: Boolean = false): String = // ...
def pretty(tree: List[Tree], showFields: Boolean = false): String = // ...
def pretty(tree: Option[Tree], showFields: Boolean = false): String = // ...

工作环境

def pretty(input: CanPretty, showFields: Boolean = false): String = {
  input match {
    case TreeCanPretty(tree)       => prettyTree(tree, showFields)
    case ListTreeCanPretty(tree)   => prettyList(tree, showFields)
    case OptionTreeCanPretty(tree) => prettyOption(tree, showFields)
  }
}

sealed trait CanPretty
case class TreeCanPretty(tree: Tree) extends CanPretty
case class ListTreeCanPretty(tree: List[Tree]) extends CanPretty
case class OptionTreeCanPretty(tree: Option[Tree]) extends CanPretty

import scala.language.implicitConversions
implicit def treeCanPretty(tree: Tree): CanPretty = TreeCanPretty(tree)
implicit def listTreeCanPretty(tree: List[Tree]): CanPretty = ListTreeCanPretty(tree)
implicit def optionTreeCanPretty(tree: Option[Tree]): CanPretty = OptionTreeCanPretty(tree)

private def prettyTree(tree: Tree, showFields: Boolean): String = "fun ..."
private def prettyList(tree: List[Tree], showFields: Boolean): String = "fun ..."
private def prettyOption(tree: Option[Tree], showFields: Boolean): String = "fun ..."

一种可能的情况是

  def foo(a: Int)(b: Int = 10)(c: String = "10") = a + b + c
  def foo(a: Int)(b: String = "10")(c: Int = 10) = a + b + c

编译器会困惑于要调用哪一个。为了防止其他可能的危险，编译器将最多允许一个重载的方法具有默认参数。

只是我的猜测：-)

我的理解是，使用默认参数值的已编译类中可能存在名称冲突。我已经看到了一些主题中提到的类似内容。

命名参数规范位于此处：http : //www.scala-lang.org/sites/default/files/sids/rytz/Mon,%202009-11-09,%2017 :29/named-args.pdf

它指出：

 Overloading If there are multiple overloaded alternatives of a method, at most one is
 allowed to specify default arguments.

因此，目前无论如何，它是行不通的。

您可以执行类似于Java中的操作，例如：

def foo(a: String)(b: Int) =  a + (if (b > 0) b else 42)