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

Question

Si bien puede haber casos válidos donde tales sobrecargas de métodos podrían volverse ambiguas, ¿por qué el compilador no permite código que no es ambiguo en tiempo de compilación ni en 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 estas restricciones no se puede aflojar un poco?

Especialmente cuando la conversión de código Java sobrecargado a Scala los argumentos predeterminados son muy importantes y no es agradable averiguar después de reemplazar un montón de métodos de Java por un método de Scala que la especificación/compilador impone restricciones arbitrarias.

Answer 1

me gustaría citar Lukas Rytz (de here):

La razón es que queríamos una denominación esquema determinista para los métodos generados cuales devolver argumentos por defecto.Si se escribe

def f(a: Int = 1)

el compilador genera

def f$default$1 = 1

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

Una solución para la futura versión Scala podría ser incorporar nombres de tipo de los argumentos no predeterminados (los que están en el comienzo de un método, que desambiguar versiones sobrecargado) en el esquema de nomenclatura, 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 así como:

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

Alguien dispuesto a write a SIP proposal?

Answer 2

Si llamó al foo() ¿cuál debería invocar?

Answer 3

no puedo responder a su pregunta, pero aquí es una solución:

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 muy largas arg que difieren sólo en un arg, puede ser que valga la pena ...

Answer 4

Sería muy difícil obtener una especificación legible y precisa para las interacciones de resolución de sobrecarga con argumentos predeterminados. Por supuesto, para muchos casos individuales, como el presentado aquí, es fácil decir lo que 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.

Answer 5

Según tengo entendido, puede haber colisiones de nombres en las clases compiladas con valores de argumento predeterminados. He visto algo a lo largo de estas líneas mencionado en varios hilos.

La especificación argumento con nombre 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. 

Así que, por el momento, en todo caso, que no va a trabajar.

se podría hacer algo parecido a lo que podría hacer en Java, por ejemplo:

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

Answer 6

Uno de los escenarios posibles 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 será confundido acerca de cuál de ellos para llamar. En la prevención de otros posibles peligros, el compilador permitiría como mucho un método sobrecargado tiene argumentos predeterminados.

Sólo mi conjetura :-)