Fix #2066: Don't qualify private members in SelectionProto's...

[odersky]

... unless they would be accessible in the given context.

[liufengyun]

The fix fails the following case if we change private to protected:

class Foo

object Test {
  implicit class One(x: Foo) {
    def meth: Unit = {}
  }

  implicit class Two(x: Foo) {
    protected def meth: Unit = {}    //  <==== change private to protected
  }

  def test(foo: Foo): Unit = {
    foo.meth
  }
}

[odersky]

The fix fails the following case if we change private to protected:

That's expected. private behaves differently from the other modifiers. For private/non-private we have different ways to search. For the other modifiers we search first, and then check that the result is accessible. But that check plays no role in (say) overloading resolution or implicit search. This has been always like this and it would be really hard to change.

[smarter]

Is this as expected? This doesn't compile:

class Foo

object Test {
  implicit def two(x: Foo): Two = new Two(x)

  class Two(x: Foo) {
    private def meth: Unit = {}

    def test2(foo: Foo): Unit = {
      foo.meth
    }
  }
}

But this does:

class Foo

object Test {

  class Two(x: Foo) {
    implicit def two(x: Foo): Two = new Two(x)

    private def meth: Unit = {}

    def test2(foo: Foo): Unit = {
      foo.meth
    }
  }
}

(Both fail with scalac)

[odersky]

Is this as expected? This doesn't compile:

No, this is weird. It looks like we can't do a good job distinguishing here without losing a lot of implicit cachability. So I'll change it to scalac's behavior to only look for non-private members.

[smarter]

Okay, this will require a spec change I think since the spec only mentions accessibility: http://www.scala-lang.org/files/archive/spec/2.12/07-implicits.html#views

[odersky]

So, does that mean scalac is also in disagreement with the spec here?

[smarter]

I think so yes, but I haven't looked closely.