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

spurious warning on implicit definition being not applicable #7441

Closed
scabug opened this issue May 1, 2013 · 6 comments
Closed

spurious warning on implicit definition being not applicable #7441

scabug opened this issue May 1, 2013 · 6 comments
Assignees

Comments

@scabug
Copy link

scabug commented May 1, 2013

object Test {
  object Bar {
    def apply(xs: List[Any]): Int = 0
    def test = apply(1)
  } 
  implicit def foo = 1
}

produces:

 found   : Int(1)
 required: List[Any]
 Note: implicit method foo is not applicable here because it comes after the application point and it lacks an explicit result type
    def test = apply(1)
                     ^
one error found

which is annoying and confusing. Maybe before producing the addendum we could force the completer and really check which of the implicits could be useful in that position?
Probably related to #5265.

@scabug
Copy link
Author

scabug commented May 1, 2013

Imported From: https://issues.scala-lang.org/browse/SI-7441?orig=1
Reporter: @hubertp
See #7486

@scabug
Copy link
Author

scabug commented May 2, 2013

@paulp said:
scala/scala#2488

@scabug
Copy link
Author

scabug commented Jul 8, 2013

@hubertp said:
and related: scala/scala#2547

@scabug
Copy link
Author

scabug commented Jul 9, 2013

@retronym said:
Reverted due to #7486. Reopening.

We might be able to exclude implicits like:

def a2b(a: A) = <expr>

by approximating the type as A => ?. and seeing if that is applicable. But we can never force the return type.

@scabug
Copy link
Author

scabug commented Jul 9, 2013

@hubertp said:
Ah, thanks. Sorry for the confusion.

@scabug
Copy link
Author

scabug commented Nov 21, 2013

@retronym said:
I'm declaring this one unfixable. I think the best way forward would be to deprecated return type inference for implicits. That's currently not possible for implicit objects and classes, though.

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

No branches or pull requests

2 participants