New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
resolution fails paramters by-name followed by varargs vs parameter by-name #3761
Comments
Imported From: https://issues.scala-lang.org/browse/SI-3761?orig=1 |
@som-snytt said: (This bug had to do with the specificity test trying to apply info1(=>String) to (String); the other bug with expanding the vararg in the same test.) The fixes addressing the bugs were straightforward, but I got ambitious. Namely, I'd like this to work: class Tri {
def foo(m: =>String,n: =>String) = m +" "+ n + "!"
def foo(m: =>String,n: String) = m +" "+ n + "!!"
def foo(m: String,n: =>String) = m +" "+ n + "!!!"
def foo(m: String,n: String) = m +" "+ n + "!!!!"
// match on foo(String,=>String)
def bar(m: String,n: =>String) = foo(m,n)
}
object Test {
def main(args: Array[String]) {
val tri = new Tri
println(tri.bar("hello","world"))
}
} The motivation is that you can overload m(A) and m(=>A) but then it's difficult to disambiguate in client code because you can't name =>A as in hypothetical application m(null: =>A). You get your by-name API back by using a different interface or a proxy method as above, if the proxy would select the args that match best. The spec is actually silent on this issue. If =>A is not selected on shape (as though it were ()=>A, it seems to me that m(=>A) is more specific than m(A) [since we can apply m(=>A) to (A) only by a special case and not by a conversion]. Whatever, that's not intuitive. My patch adds a tie-breaker where the winner has to match the by-namedness of the applied args exactly. See above. This is an edge case, but has the benefit of being simple and enabling something that's otherwise hard (without putting a can-opener to the complexity worms gathering dust in the tackle box). |
@som-snytt said: The behavior described in the previous comment is under a private option -Yresolve-by-name. As described in the commit, the patch is to handle isCompatible test for A and =>A explicitly. |
@retronym said: |
@som-snytt said: |
@som-snytt said: The patch doesn't include the variant overloading resolution. Sniff. |
The by-value methods can be handled by not the by-name methods.
The text was updated successfully, but these errors were encountered: