You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Treat functional interfaces specially in overloading resolution
Overloading resolution had two stages to determine when an alternative is applicable"
1. Match with subtyping only
2. Match with implicit conversions and SAM conversions
If some alternatives are eligible under (1), only those alternatives are considered.
If no alternatives are eligible under (1), alternatives are searched using (2).
This behavior is different from Scala 2, which seems to use SAM conversions more aggressively.
I am not sure what Scala 2 does. One obvious change would be to allow SAM conversions under (1).
But I am reluctant to do that, since a SAM conversion can easily be introduced by accident.
For instance, we might have two overloaded variants like this:
```scala
def foo(x: C) = ...
def foo(x: A => B) = ...
foo((x: A) => x.toB)
```
Now, if `C` happens to be a SAM type that has an abstract method from A to B, this would be ambiguous.
Generally, it feels like a SAM conversion could too easily be considered by accident here.
On the other hand, if `C` was marked with `@FunctionalInterface` it would explicitly expect function
arguments, so then we should treat it as morally equivalent to a function type in Scala.
This is what this commit does. It refines the priority for searching applicable methods as follows:
1. Match with subtyping and with SAM conversions to functional interfaces
2. Match with implicit conversions and SAM conversions to other types
0 commit comments