ambiguous references which aren't

[scabug]

I have pervasively utilized the import noise reduction available when one defines type aliases in a package object:

  type IOException    = java.io.IOException
  type InputStream    = java.io.InputStream

Unfortunately this interacts needlessly poorly with the rest of the world. One adds a seemingly compilable file from elsewhere to find:

[error] file.scala:44: reference to InputStream is ambiguous;
[error] it is both defined in trait Foo and imported subsequently by 
[error] import java.io.{InputStream, OutputStream}

scalac is perfectly well aware that these normalize to the same type. I have no problem with this being an error if they are not the same type, but this one is purely spurious, and it really hamstrings the otherwise boundless joy of aliasing commonly used types into one's package.

Addendum: it is particularly intrusive because even wildcard imports incur an ambiguity error, so for instance:

  // package wide
  type Settings = scala.tools.nsc.Settings
  // some new file
  import scala.tools.nsc._
  // and... error.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-3836?orig=1
Reporter: @paulp
Other Milestones: 2.10.0

[scabug]

@harrah said:
Bringing typing into imports is along the lines of the request in #2551. I would guess the same resolution of that issue applies here.

[scabug]

@paulp said:
Replying to [comment:3 harrah]:

Bringing typing into imports is along the lines of the request in #2551. I would guess the same resolution of that issue applies here.

Don't jinx me bub. I see the similarity, but #2551 is far more ambitious: I'm not looking to overload anything or have the compiler do anything clever, just to chill out about stomping the entire build. I'd be happy with any number of tiny changes, I'd take a compiler option, hidden secret password and handshake, anything which uncripples the described use case.

Plus I'll gladly implement it myself. I am not #2551! (You are #6.)

[scabug]

@harrah said:
Just pointing out that you'll probably need a SID for it to be mainstream. I figured if you wanted it to be a secret option, you wouldn't have filed a bug for it. It seems that this would be properly handled by one of the various 'export' proposals (that have unfortunately never gone anywhere).

[scabug]

@odersky said:
I had a close look at it. It's not a simple fix. It would conflate symbol lookup (that's where the error gets reported) with symbol completion and typing, and that would complicate the language to no small degree. So it's a wont fix for now, barring a SID.

[scabug]

@adriaanm said:
Tentative fix in paulp/scala@394f84804
Let's reopen the case and discuss it during the next meeting.

[scabug]

@paulp said:
Actually you'll want https://github.com/paulp/scala/tree/issue/3836 , that'll teach me to link directly to a commit rather than to a branch name.

[scabug]

@adriaanm said:
Martin says we should do this.

[scabug]

@paulp said (edited on Jul 6, 2012 4:48:39 AM UTC):
scala/scala#834

[scabug]

@paulp said:
And ddcb351a2e .