Почему компилятор Scala запрещает перегруженные методы с аргументами по умолчанию?

Было бы очень сложно получить читаемую и точную спецификацию для взаимодействия перегрузки разрешения с аргументами по умолчанию. Конечно, для многих отдельных случаев, таких как представленный здесь, легко сказать, что должно произойти. Но этого недостаточно. Нам нужна спецификация, которая решает все возможные угловые случаи. Перегрузочное разрешение уже очень сложно определить. Добавление аргументов по умолчанию в миксе будет еще сложнее. Вот почему мы решили отделить их.

Я не могу ответить на ваш вопрос, но вот обходной путь:

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
}

Если у вас есть два очень длинных списка аргументов, которые отличаются только одним аргументом, это может стоить проблем...

То, что сработало для меня, - это переопределить (стиль 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"

Это гарантирует компилятору, какое разрешение вы хотите в соответствии с текущими параметрами.

Одним из возможных сценариев является

  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

Компилятор будет смущен, о котором нужно позвонить. В предотвращении других возможных опасностей компилятор разрешил бы не более одного перегруженного метода иметь аргументы по умолчанию.

Просто мое предположение: -)

Вот обобщение ответа @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 = // ...

Workarround

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 ..."

Я понимаю, что в скомпилированных классах со значениями аргументов по умолчанию могут возникать конфликты имен. Я видел что-то в этом направлении, упомянутое в нескольких потоках.

Именованный аргумент spec здесь: 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)

Если вы вызвали foo(), который он должен вызвать?