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
compiler infers non-wildcard existential type for case-module-unapply #6541
Comments
Imported From: https://issues.scala-lang.org/browse/SI-6541?orig=1 |
@szeiger said: Option[(A, B[_$1 forSome { type _$1 }])] aka Option[(A, B[_])] right? |
@Blaisorblade said: |
@adriaanm said: |
@Blaisorblade said: It seems that in the body of the method, _$1 should be bound by matching on B's type: x$0.b match {case b: B[t] => Some((x$0.a, b))}. But maybe _$1 is in fact bound in some equivalent way, which can only be seen in the AST (trying to take a look now). Alternatively, the AST is just inconsistent and this is not detected, but that doesn't sound likely. But I don't get what the impact of the bug is from the bug report. Looking at the thread, I see that:
|
@retronym said: |
@paulp said: scala> case class Foo(clazz: Class[_])
<console>:7: warning: inferred existential type Option[Class[_$1]] forSome { type _$1 }, which cannot be expressed by wildcards, should be enabled
by making the implicit value scala.language.existentials visible.
This can be achieved by adding the import clause 'import scala.language.existentials'
or by setting the compiler option -language:existentials.
See the Scala docs for value scala.language.existentials for a discussion
why the feature should be explicitly enabled.
case class Foo(clazz: Class[_])
^
defined class Foo |
@gkossakowski said: |
@retronym said: |
Eyal Roth (errr) said (edited on Nov 1, 2016 2:08:39 PM UTC): |
@SethTisue said: |
@lrytz said: |
@lrytz said: |
@lrytz said: |
@lrytz said: |
generates the following unapply method
The problematic return type
is not generated together with the unapply method, but inferred by the compiler (when the generated method is type-checked). Martin suggests to provide the return type explicitly.
Also, in the body of the unapply, what is the type name _$1 is bound to?
The text was updated successfully, but these errors were encountered: