Question

While there might be valid cases where such method overloadings could become ambiguous, why does the compiler disallow code which is neither ambiguous at compile time nor at run time?

Example:

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

Are there any reasons why these restrictions can’t be loosened a bit?

Especially when converting heavily overloaded Java code to Scala default arguments are a very important and it isn’t nice to find out after replacing plenty of Java methods by one Scala methods that the spec/compiler imposes arbitrary restrictions.

Answer 1

I’d like to cite Lukas Rytz (from here):

The reason is that we wanted a deterministic naming-scheme for the
generated methods which return default arguments. If you write

def f(a: Int = 1)

the compiler generates

def f$default$1 = 1

If you have two overloads with defaults on the same parameter
position, we would need a different naming scheme. But we want to keep
the generated byte-code stable over multiple compiler runs.

A solution for future Scala version could be to incorporate type names of the non-default arguments (those at the beginning of a method, which disambiguate overloaded versions) into the naming schema, e.g. in this case:

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

it would be something like:

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

Someone willing to write a SIP proposal?