Inconsistency between inferred and declared typing for types with restricted visibility

[olafurpg]

I was able to reproduce a Scala 2.12.4 bug with dotty 0.5.0-RC1, see original ticket scala/bug#1800

I encountered this bug today running scalafix ExplicitResultTypes on the akka codebase, here is a minimized reproduction

package a {
  private[a] object b {
    class B
  }
  object c { def getB: b.B = new b.B() }
}
package d {
  object e {
    val f = a.c.getB
    // val g: a.b.B = a.c.getB // Error

// scala 2.x
// foo.scala:10: error: object b in package a cannot be accessed in package a
//     val g: a.b.B = a.c.getB
//              ^

// dotty
// -- Error: foo.scala:10:13 ------------------------------------------------------
// 10 |    val g: a.b.B = a.c.getB // Error: does not compile
//    |           ^^^
//    |object b in package a cannot be accessed as a member of a.type from module class e$.
// one error found
  }
}

[smarter]

I think we just shouldn't allow private-qualified types to leak, just like we already disallow private types from leaking: https://github.com/lampepfl/dotty/blob/52bddff77b39b1169d030094825b2a0d5e1b7d5b/compiler/src/dotty/tools/dotc/typer/Checking.scala#L382-L402

[odersky]

It's a long-standing very thorny issue. The best way forward might be to eliminate qualified private altogether.

[odersky]

I would argue we should not try to solve this before we have decided on the fate of qualified private.

[sjrd]

By qualified private do you mean private[enclosing]? If yes, you can't possibly eliminate that altogether. That's the only thing that allows to maintain a semblance of distinction between a public API and a private API. Without that, evolving libraries in backward source/binary compatible ways will become completely impossible.