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
recursive value xxx needs type #7486
Comments
Imported From: https://issues.scala-lang.org/browse/SI-7486?orig=1 |
@retronym said: |
@retronym said: object Test{
var locker = 0
// remove implicit, or change to `locker = locker + 1` to make it compile.
implicit val davyJones0 = {
locker += 0
0
}
} My bisection tools seem to be failing me: they indicate that the first failing commit is https://github.com/scala/scala/commit/2.10.x~11%5E2, which was just a checkfile update. |
@paulp said: |
@paulp said: |
@retronym said: package org.scalatest
import org.scalautils.Equality
import org.scalautils.NormalizingEquality
import org.scalautils.Normalization
import org.scalautils.StringNormalizations._
import SharedHelpers._
class ListShouldContainSpec extends Spec with Matchers {
val some: Option[String] = Some("hi")
{
val wrap = ListShouldContainSpec.this.convertToAnyShouldWrapper[Option[String]](ListShouldContainSpec.this.some)
// forward reference to `implicit val e` reported in 2.10.2, in 2.10.1 companion implicit for Equality[String] was used as the implicit argument to `being`.
wrap.should(contain("HI"))(ListShouldContainSpec.this.after.being(org.scalautils.StringNormalizations.lowerCased)/*(implicitly[Equality[String]])*/)
wrap.should(contain("HI"))(ListShouldContainSpec.this.after.being(org.scalautils.StringNormalizations.lowerCased)/*(implicitly[Equality[String]])*/)
// annotate type and the forward reference error is issued under 2.10.1
implicit val e /*Equality[String]*/ = new Equality[String] {
def areEqual(a: String, b: Any): Boolean = a != b
}
}
} |
@paulp said: It is not intuitive, and it will definitely not lead to a very consistent programming experience, that there can be an implicit in the same block which has the type being sought, and it will be leapfrogged to go searching in the companion scope, but only if it has no declared type. This seems like quite a perversion of the reason there is a difference, that being cycle avoidance. Maybe there is some backstory here which I can't see because it's stored in a lead box at lex luthor's house. |
@retronym said: As per the mail I just sent (which I'll reproduce here for the record), this facet of implicit search isn't specced, so the status quo is the spec. The implementation intends to exclude I guess as the 2.10.2 guardian, James ought to make a call on what to do. Two questions to answer: 1) leave it or revert it; 2) invest time into pinning down the behaviour with tests or deem it effectively untestable.
|
@retronym said: Assigning to you to make a call on the course of action. |
@retronym said: |
@adriaanm said: |
@JamesIry said: |
@paulp said: |
@retronym said: |
@JamesIry said: |
@paulp said: |
@adriaanm said: |
@retronym said: |
@retronym said: Here's a prototype: https://github.com/retronym/scala/compare/topic/warn-discarded-implicit?expand=1 However, this does not take into account the way that implicit search participates in type inference. If the expected type of the implicit search contains an undetermined type variable, the discarded implicit might not appear viable after inference has occurred. |
With 2.10.2-SNAPSHOT (2.10.2-20130515-155912-70e2ead142) compilation error is reported for the following code in akka-testkit.
https://github.com/akka/akka/blob/master/akka-testkit/src/test/scala/akka/testkit/AkkaSpecSpec.scala#L67
It compiles fine when I remove the implicit, which we actually don't need here.
This is compiling fine with 2.10.1.
The text was updated successfully, but these errors were encountered: