Embora possa haver casos válidos em que essas sobrecargas de método possam se tornar ambíguas, por que o compilador desaprova o código que não é ambíguo no tempo de compilação nem no tempo de execução?
Exemplo:
// 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 ...
Existem razões pelas quais essas restrições não podem ser um pouco mais flexíveis?
Especialmente ao converter códigos Java altamente sobrecarregados em argumentos padrão do Scala, é muito importante e não é bom descobrir após a substituição de muitos métodos Java por um método Scala que o spec / compiler impõe restrições arbitrárias.
object Test { def a[A](b: Int, c: Int, d: Int = 7): Unit = {}; def a[A](a:String, b: String = ""): Unit = {}; a(2,3,4); a("a");}