Closed
Description
import java.util._
object TestOkay {
def sort(x: java.util.Comparator[_ >: String]) = ()
sort((a: String, b: String) => a.compareToIgnoreCase(b))
}
object TestOkay2 {
def sort[T](x: java.util.Comparator[_ >: T]) = ()
sort((a: String, b: String) => a.compareToIgnoreCase(b))
}
object TestOkay3 {
def sort[T](xs: Option[T], x: java.util.Comparator[_ >: T]) = ()
sort(Some(""), (a: String, b: String) => a.compareToIgnoreCase(b))
}
object TestKoOverloaded {
def sort[T](xs: Option[T]) = ()
def sort[T](xs: Option[T], x: java.util.Comparator[_ >: T]) = ()
sort(Some(""), (a: String, b: String) => a.compareToIgnoreCase(b))
}
Overloading resolution type checks the function literal without an expected type, and then discards the overloaded alternative as Function1
doesn't conform to Comparator
.
Java can handle this, presumably because it filters overloaded alternatives based on arity first (we filter them based on isApplicable
, which might tuple args, add defaults, etc).
Maybe this will wind up as a wont-fix, but we should document the limitation in the SAM SIP for 2.12.