Skip to content
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

Very bad: Change in variable scoping behavior in anonymous inner classes in 2.11-RC1 #8371

Closed
scabug opened this issue Mar 6, 2014 · 5 comments

Comments

@scabug
Copy link

scabug commented Mar 6, 2014

Scala seems to be picking out the wrong instance variable:

import scala.collection.mutable._

class Beam { outer =>
  private val queue = new ArrayBuffer[Int]()

  def foo {
    outer.queue += 42
    new Beam {
      println(queue)
      assert(queue.length == 0) // boom
    }
  }
}

// 2.10: prints ArrayBuffer()
// 2.11: prints ArrayBuffer(42) and then throws assertion error.
(new Beam).foo() 
@scabug
Copy link
Author

scabug commented Mar 6, 2014

Imported From: https://issues.scala-lang.org/browse/SI-8371?orig=1
Reporter: @dlwh
Affected Versions: 2.11.0-RC1

@scabug
Copy link
Author

scabug commented Mar 7, 2014

@adriaanm said (edited on Mar 7, 2014 1:05:24 AM UTC):
regressed fixed in adriaanm/scala@8d96380

@scabug
Copy link
Author

scabug commented Mar 7, 2014

@adriaanm said:
Minimized:

class Foo[T] {
  private val bar: T = ???
 
  new Foo[String] { bar: String }
}

@scabug
Copy link
Author

scabug commented Mar 7, 2014

@adriaanm said:
I was confused (again!) as well, but this is actually as specified. Here's another example of where this surprised: ktoso/akka@e7ffaeb
bar is private, so it won't be seen as a member of a subclass of Foo. It is however in scope due to the lexical nesting of the bar: String expression.

We should probably add this to the release notes...

@scabug scabug closed this as completed Mar 7, 2014
@scabug
Copy link
Author

scabug commented Mar 7, 2014

@dlwh said:
Huh, sorry about that!

The change does show up in a lot of places. So the new (implemented) semantics of private are that the name is actually totally passed over, rather than being a compile-time error? That does make more sense then the way it's been, I guess.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants