Imported From: https://issues.scala-lang.org/browse/SI-3160?orig=1
Reporter: @retronym

@axel22 said:
Is it ok to assign this to you, Miles? The fix is not very urgent.

Thanks

@milessabin said:
Sure ... I'll see what I can do.

@paulp said:
See also #2133 (and #3285 which I just closed as duplicate of that.)

@paulp said:
Based on the resolution of #2133, this isn't even a bug unless there will
be different rules for java. Martin said:

Stephane's original example is not covered by the spec, which says that
all importable members are counted. A member is importable as long as
it is not private[this]. Why this wording? Because an inner class might
validly import the private members of its companion object.  

That would be a distressing outcome, and not just for this. It seems like we shouldn't have to pollute the namespace of everyone who imports a package with a bunch of inaccessible symbols, just to keep the door open for some hypothetical inner classes.

Also, see previous ticket of mine #3836, "ambiguous references which aren't." But it's worse than I had realized at the time. You can't even use aliases in your own package, private to your own package, without ruining the package.

package object foo {
  private[foo] type InputStream = java.io.InputStream
  // oddly there is no conflict if there's no qualifier,
  // though the quote from martin would imply otherwise.
  // private type InputStream = java.io.InputStream
}

object bar {
  import foo._
  import java.io._

  var x: InputStream = null
}

// 9: error: reference to InputStream is ambiguous;
// it is imported twice in the same scope by
// import java.io._
// and import foo._
//   var x: InputStream = null
//          ^
// one error found

I think this is terribly unfortunate. And should be treated as an
encapsulation failure, not a mere inconvenience (though it is quite
inconvenient.)

In the wontfix for #3836 martin says he doesn't want name lookup to start intruding on symbol resolution and typing. That's fine. I see this as like implicit resolution or type inference, where there is often some ambiguity which would be resolved if the process continued. An implicit is ruled out because the type parameters don't match its bounds, etc.

But the biggest thing is that private names which affect an unrelated class's namespace cannot really be called private.

@Blaisorblade said (edited on Mar 12, 2012 12:51:58 AM UTC):
Paul, before reading your comment, I added a comment to #2133, where I also complained (for the same reasons you give above about failure of encapsulation), and reopened that bug:
https://issues.scala-lang.org/browse/SI-2133?focusedCommentId=56541#comment-56541
The reasons you give above seem more valid, so maybe you should close the bug again. Sorry for the noise!

scala/scala#1521

@som-snytt should this ticket be closed?

scala/scala#5970