¿Por qué el compilador Scala no permite métodos sobrecargados con argumentos predeterminados?

Si bien puede haber casos válidos en los que tales sobrecargas de métodos podrían volverse ambiguas, ¿por qué el compilador no permite el código que no es ambiguo en el momento de la compilación ni en el tiempo de ejecución?

Ejemplo:

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

¿Hay alguna razón por la cual estas restricciones no se pueden aflojar un poco?

Especialmente cuando la conversión de código Java muy sobrecargado a argumentos predeterminados de Scala es muy importante y no es bueno descubrir después de reemplazar muchos métodos Java por uno de los métodos Scala que el compilador / especificación impone restricciones arbitrarias.

Me gustaría citar a Lukas Rytz (desde aquí ):

La razón es que queríamos un esquema de nombres determinista para los métodos generados que devuelven argumentos predeterminados. Si tú escribes

def f(a: Int = 1)

el compilador genera

def f$default$1 = 1

Si tiene dos sobrecargas con valores predeterminados en la misma posición de parámetro, necesitaríamos un esquema de nomenclatura diferente. Pero queremos mantener estable el código de bytes generado en múltiples ejecuciones del compilador.

Una solución para la futura versión de Scala podría ser incorporar nombres de tipo de los argumentos no predeterminados (los que se encuentran al comienzo de un método, que desambigua las versiones sobrecargadas) en el esquema de nombres, por ejemplo, en este caso:

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

sería algo como:

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

Alguien dispuesto a escribir una propuesta SIP ?

Sería muy difícil obtener una especificación legible y precisa para las interacciones de la resolución de sobrecarga con argumentos predeterminados. Por supuesto, para muchos casos individuales, como el presentado aquí, es fácil decir qué debería suceder. Pero eso no es suficiente. Necesitaríamos una especificación que decida todos los casos de esquina posibles. La resolución de sobrecarga ya es muy difícil de especificar. Agregar argumentos predeterminados en la mezcla lo haría aún más difícil. Es por eso que hemos optado por separar los dos.

No puedo responder a su pregunta, pero aquí hay una solución alternativa:

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
}

Si tiene dos listas arg muy largas que difieren en un solo argumento, podría valer la pena ...

Lo que funcionó para mí es redefinir (estilo Java) los métodos de sobrecarga.

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"

Esto garantiza al compilador la resolución que desea de acuerdo con los parámetros actuales.

Aquí hay una generalización de la respuesta de @Landei:

Lo que realmente quieres:

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

Uno de los posibles escenarios es

  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

El compilador estará confundido sobre a quién llamar. Para evitar otros posibles peligros, el compilador permitiría que, como máximo, un método sobrecargado tenga argumentos predeterminados.

Solo mi suposición :-)

Tengo entendido que puede haber colisiones de nombres en las clases compiladas con valores de argumento predeterminados. He visto algo en este sentido mencionado en varios hilos.

La especificación del argumento nombrado está aquí: http://www.scala-lang.org/sites/default/files/sids/rytz/Mon,%202009-11-09,%2017:29/named-args.pdf

Afirma:

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

Entonces, por el momento, en cualquier caso, no va a funcionar.

Podría hacer algo como lo que podría hacer en Java, por ejemplo:

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