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
Are specialPolyClass ParamTypes inferable as type arguments or not? #5991
Comments
Imported From: https://issues.scala-lang.org/browse/SI-5991?orig=1 |
@adriaanm said: |
@adriaanm said: |
@retronym said (edited on Jul 2, 2012 8:33:38 PM UTC): object Repeater extends ((Int*) => Unit) {
def apply(x: Int*) {}
} but not do much more with it; it is treated as a subtype of More discussion over at #6016. It might be prudent to disallow
scala> def f(a: (=> Any) => Any) = a(???)
f: (a: => Any => Any)Any
scala> f(x => 0)
res1: Any = 0 Eta expansion retains the by-name-ness: scala> def foo(z: Any)(a: => Int) = z
foo: (z: Any)(a: => Int)Any
scala> (foo(0) _)(???)
res2: Any = 0 So I'm not sure where to take this. If we're going to follow through with the tough stance on |
@adriaanm said (edited on Jul 3, 2012 4:23:12 PM UTC): Instead, when eta-expanding, we should desugar them into the appropriate instantiations of FunctionN, or possibly a subclass such as ByNameFunction and VarargFunction. Unfortunately we don't have the resources to fix this right now. |
@SethTisue maybe close
Prudence prevailed.
The behavior under eta-expansion was added to the spec. It's possible that by-name as parameterless method type is sufficiently explanatory. The spec doesn't have to say (as everyone thinks to themselves) that passing the arg "really creates a function On the question, how are
|
(Using Manifests to avoid interacting with #5990.)
Okay, so no then!
isItInferableAsATypeArg(ByName)
Okay, so yes then?
Somewhere in here is a bug, right?
The text was updated successfully, but these errors were encountered: