This code:

class MyClass {
    def something(in: String): String = {
        in + "_z"
    }

    def something: (String) => String = {
        case _ => "Fixed"
    }
}

val my = new MyClass()

println(List("x", "y").map(my.something))

Prints List(Fixed, Fixed).

The type checker is calling the no-argument variant of my.something(), and then silently taking the return type and passing it to map(). This ignores the other matching one-argument version of my.something.

The below line (arguably correctly) produces a compile error about an "ambiguous reference to overloaded definition":

val fun: String => String = my.something(_)

Adding parentheses to the no-argument definition of the method removes the issue. Changing the return type of the no-argument method to be anything other than String => String removes the issue.

I think this is incorrect behavior; where there is a conflict between the result of an implicit conversion (the my.something() return value) and an unconverted correct type, either the unconverted type should win or a compile error should be thrown telling the user about ambiguity. In other words, the above code should either output List(x_z, y_z) or fail to compile. Currently the implicitly converted version is silently taking precedence.