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

Jump to bottom

ambiguous references which aren't #3836

Closed
scabug opened this issue Sep 11, 2010 · 10 comments
Closed

ambiguous references which aren't #3836

scabug opened this issue Sep 11, 2010 · 10 comments
Assignees
@paulp
Milestone
2.10.0-M4

Comments

@scabug
Copy link

scabug commented Sep 11, 2010

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
Copy link
Author

scabug commented Sep 11, 2010

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

@scabug
Copy link
Author

scabug commented Sep 13, 2010

@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
Copy link
Author

scabug commented Sep 13, 2010

@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
Copy link
Author

scabug commented Sep 13, 2010

@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
Copy link
Author

scabug commented Oct 16, 2010

@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
Copy link
Author

scabug commented Jun 14, 2012

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

@scabug
Copy link
Author

scabug commented Jun 14, 2012

@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
Copy link
Author

scabug commented Jul 3, 2012

@adriaanm said:
Martin says we should do this.

@scabug
Copy link
Author

scabug commented Jul 5, 2012

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

@scabug scabug closed this as completed Jul 6, 2012
@scabug
Copy link
Author

scabug commented Jul 6, 2012

@paulp said:
And ddcb351a2e .

@scabug scabug added this to the 2.10.0-M4 milestone Apr 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@paulp paulp

Labels
None yet
Projects
None yet
Milestone
2.10.0-M4
Development

No branches or pull requests
2 participants
@paulp @scabug