Override method with implicit methods.

[nicolasstucki]

Currently we are unable to override a method with an implicit method as the implicit method is not a subtype of the plain method. This is in used in the definitions of the synthetic symbols for ImplicitFunctionN but it does not work properly. I found the following two issues

• Dotty complains when we try to override a method with its equivalent implicit method.
• We are forced to implement ImplicitFunctionN.apply without the implicit. Making the function class implementing ImplicitFunctionN behave as a FunctionN.

object Test {
  def main(args: Array[String]): Unit = {
    implicit val x: String = "hello"
    val i0: Int = new Fun0().apply

    val i1: Int = new Fun1().apply
    //                ^^^^^^^^^^^^
    //                missing arguments for method apply in class Fun1
    //                follow this method with `_' if you want to treat it as a partially applied function

    val i2: Int = new Fun2().apply // works as expected
  }
}

class Fun0 extends ImplicitFunction1[String, Int] {
  def apply(implicit x: String): Int = 42
  // overriding method apply in trait Function1 of type (v1: String)Int;
  //   method apply of type (implicit x: String)Int has incompatible type
}

class Fun1 extends ImplicitFunction1[String, Int] {
  def apply(x: String): Int = 43
}

class Fun2 {
  def apply(implicit x: String): Int = 44
}

class A {
  def foo(x: String): Unit = ()
}

class B extends A {
  def foo(implicit x: String): Unit = ()
  // overriding method foo in trait A of type (x: String)Unit;
  //   method foo of type (implicit x: String)Unit has incompatible type
}

[odersky]

That's intentional. Implicit methods should not be able to override normals methods. ImplicitFunctionN is an exception. it should not undergo this check.

[odersky]

And, I am not sure at all we want to make implicit function classes extensible. Make them final instead?

[retronym]

I believe that treating the implicit modifier as significant in subtyping is incorrect.

Here's an example in scalac that lets you override without the override keyword:

scala> class C[A] { def foo(a: A) = "c" }
class D extends C[String] { def foo(implicit s: String) = "d" }
(new D(): C[String]).foo("")
defined class C
defined class D
res3: String = d

A related bug: SI-3653, was fixed by removing the implicit modifier in the Uncurry info transform.

Wouldn't it be better to treat the method types as equivalent, and report the mismatched implicit modifiers in the overriding pairs analysis in RefChecks?

[retronym]

Another manifestation:

scala> class C[A] { final def foo(a: A) = "c" }; class D extends C[String] { def foo(implicit s: String) = "d" }; new D
java.lang.VerifyError: class D overrides final method foo.(Ljava/lang/Object;)Ljava/lang/String;
  at java.lang.ClassLoader.defineClass1(Native Method)

[nicolasstucki]

Making the methods equivalent would also fix a similar issue with overloading #2002.

I will also try to see if it is possible to decouple ImplicitFunctionN from FunctionN to remove this exceptional override.

[retronym]

The same hole exists for multiple parameter lists:

scala> class C[A] { final def foo(a: A)(b: A) = "c" }; class D extends C[String] { def foo(s: String, t: String) = "d" }; new D
java.lang.VerifyError: class D overrides final method foo.(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/String;
  at java.lang.ClassLoader.defineClass1(Native Method)

[nicolasstucki]

This is another override that is currently valid, but should not.

class A {
  def foo(implicit i: Int): Int = i + i
}

class B extends A {
  override def foo(i: Int): Int = i
}

[DarkDimius]

I don't see why last one shouldn't be valid. Both methods have the same signature and thus one overrides another.

I agree with @retronym that it would be better if implicit modifier in argument does not affect overriding relationship. Otherwise we may need to name-mangle all methods with implicit arguments.

[nicolasstucki]

The issue is not that it is not a valid override, in fact in this case it should identify it as a valid override. But we would need another check that forces implicit method to be overriden by implicit methods and non implicit method by non implicit methods.

[retronym]

It is worth noting that we already report modifier mismatches in refchecks, in the same manner as I'm proposing above, for access modifiers:

scala> class C { def foo = 1 }; class D extends C { private def foo = 2 }
<console>:11: error: overriding method foo in class C of type => Int;
 method foo has weaker access privileges; it should not be private
       class C { def foo = 1 }; class D extends C { private def foo = 2 }
                                                                ^

[retronym]

Trying out a scalac implementation in scala/scala#5722

[odersky]

I agree that we should catch this in rechecks.

[odersky]

I am still reluctant to allow arbitrary implicit/non-implicit overrides but #3692 requires that an implicit method can match a non-implicit one, since otherwise

implicit (c: C) => D  !<:   (c: C) => D

even tough

implicit (c: C) => D <: C => D

That does not seem to be reasonable. It is changed in #3704.