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

Implementation of abstract method with implicit argument #7313

Closed
scabug opened this issue Mar 29, 2013 · 5 comments
Closed

Implementation of abstract method with implicit argument #7313

scabug opened this issue Mar 29, 2013 · 5 comments
Assignees
Milestone

Comments

@scabug
Copy link

@scabug scabug commented Mar 29, 2013

If I try to compile the following code:

trait A {
   def f(i: Int): Int
}

object B extends A {
 def f(implicit i: Int) = i
}

I get error:

error: object creation impossible, since method f in trait A of type (i: Int)Int is not defined

Same with class:

error: class B needs to be abstract, since method f in trait A of type (i: Int)Int is not defined
@scabug
Copy link
Author

@scabug scabug commented Mar 29, 2013

Imported From: https://issues.scala-lang.org/browse/SI-7313?orig=1
Reporter: Pavel Glushchenko (codenamestif)
Affected Versions: 2.10.0, 2.10.1

@scabug
Copy link
Author

@scabug scabug commented Mar 30, 2013

@retronym said:
The point in the current implementation that checks this:

      case mt1 @ MethodType(params1, res1) =>
        tp2 match {
          case mt2 @ MethodType(params2, res2) =>
            // sameLength(params1, params2) was used directly as pre-screening optimization (now done by matchesQuantified -- is that ok, performancewise?)
            mt1.isImplicit == mt2.isImplicit &&
            matchingParams(params1, params2, mt1.isJava, mt2.isJava) &&
            matchesQuantified(params1, params2, res1, res2)

Originally introduced in 2005 by Martin: scala/scala@0baff37#L30R834

The spec is silent:

Two method types(§3.3.1) are equivalent if they have equivalent resulttypes, both have the same number of parameters, and corresponding parameters have equivalent types. Note that the names of parameters do not matter for method type equivalence.

Assigning to Martin for clarification; it seems to me like it's intentional and the spec needs an update.

@scabug
Copy link
Author

@scabug scabug commented Apr 21, 2013

@paulp said:
It's definitely intentional. "The spec needs an update" is a non-sequitur at this point. Yes, the spec needs an update, and I need a flying car.

@scabug
Copy link
Author

@scabug scabug commented Oct 15, 2013

@gkossakowski said:
Unassigning and rescheduling to M7 as previous deadline was missed.

@scabug
Copy link
Author

@scabug scabug commented Mar 13, 2014

@adriaanm said:
Fixed in the upcoming markdown version of the spec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants