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

bug with implicits methods declared after imports #2206

Closed
scabug opened this issue Jul 27, 2009 · 8 comments
Closed

bug with implicits methods declared after imports #2206

scabug opened this issue Jul 27, 2009 · 8 comments
Assignees
Milestone

Comments

@scabug
Copy link

scabug commented Jul 27, 2009

class A

class AX {
    def f() { }
}

import Implicits._
val a = new A
a.f()

object Implicits {
    implicit def ax(a: A) = new AX
}
discarding <script preamble>
(fragment of hello.scala):9: error: value f is not a member of this.A
a.f()
   ^

I think that either import should fail or (preferred to me, code should be compileable).

2.7.5.final

@scabug
Copy link
Author

scabug commented Jul 27, 2009

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

@scabug
Copy link
Author

scabug commented Jul 27, 2009

@paulp said:
I tend to agree that this is a bug, because given the import statement, the implicit should be made available -- however in case you are unaware, in general implicits which lexically follow the point at which you want them to work need an explicit return type to be considered. And this example does work if you supply it.

  implicit def ax(a: A): AX = new AX

@scabug
Copy link
Author

scabug commented Jul 28, 2009

@TiarkRompf said:
Paul, can you have a look if it's possible to generate a better error message?

@scabug
Copy link
Author

scabug commented Jul 30, 2009

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

Paul, can you have a look if it's possible to generate a better error message?

I probably wasn't clear in my first comment - in order to generate a better error message I need to understand why it's an error. I would have expected that explicitly importing the contents of an object, regardless of the location of that object, means that the implicits inside the object would now be eligible for statements following the import. As that is not the case, I'm not sure what the message would say.

It would certainly be nice though if when there is a type error, and the compiler has some knowledge of an ineligible implicit that would have made the error go away, if it would tell you both the implicit and why it wasn't used.

@scabug
Copy link
Author

scabug commented Sep 17, 2009

@paulp said:
I'm throwing this back to scala_reviewer as I can't do anything with it without knowing what we think should happen, or if it's an error, why it's an error. As I said above, I agree with the submitter that this code should compile.

@scabug
Copy link
Author

scabug commented Sep 22, 2009

@odersky said:
I don't think it's possible to compile this. The problem is that we have to be very careful which implicits to evaluate, for fear of falling into infinite cycles. So the best thing we could do is give a better error message. I'm reassgning back to you, Paul, but I'm also happy if you turn it into a won't fix subsequently.

@scabug
Copy link
Author

scabug commented Apr 22, 2010

@paulp said:
It's funny, it turns out the error message was in there all along, but not being printed due to a logic error. I fixed it mostly by accident working on other error messages. I'll close this as soon as I check it in.

@scabug
Copy link
Author

scabug commented Apr 27, 2010

@paulp said:
Explanatory error in trunk as of r21706.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants