Inconsistent behaviour of case classes with and without an explicit companion object

[scabug]

Writing an explicit companion object for a case class interferes with type inference for the auto-generated apply() method. Take the following code:

def f(g: (String, Int) => Any) = null

case class A(x: String, y: Int)
case class B(x: String, y: Int)
object B

val v1 = f(A.apply _)
val v2 = f(A)
val v3 = f(B.apply _)
val v4 = f(B)

v1, v2, and v3 compile.

v4 fails with:

error: type mismatch;
 found   : this.B.type (with underlying type object this.B)
 required: (String, Int) => Any
val v4 = f(B)

It seems that the explicit companion object prevents the proper Function trait from being mixed in automatically.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-4808?orig=1
Reporter: @szeiger
Affected Versions: 2.8.1, 2.9.0, 2.10.2
Duplicates #3664

[scabug]

@retronym said (edited on Sep 19, 2013 7:03:46 AM UTC):
Deferring to 2.11.x, we can't change the parentage of explictly defined companions in a binary compatible manner (someone could rely on the Function1-ness of a stdlib case companion we ship in 2.10.1, and get a linkage error with 2.10.0).

Even beyond the question of binary compatibility, I don't think that doing this is a clear cut correct decision; we should consult the community before proceeding.

[scabug]

@refried said (edited on Sep 18, 2013 10:56:15 PM UTC):
Seems like the explicit case should have the same behavior (parentage, methods added) as the auto-generated case; if it helps: maybe an annotation to flip the default behavior for the companion? This would be more user-friendly than having to manually extend Function9, and maintain the arguments in two places.

Are there some stdlib case companions that have Function1-ness that could break? Would their Function1-ness go away?

Thanks!

[scabug]

@retronym said:
From an implementation perspective, I don't think this will be straight forward. The way we add the apply/unapply to a companion is already a fragile area of the compiler, so I expect that changing the parents will be just as awkward.

We don't have a precedent for annotations controlling what parts of case class translation are performed, and I'm unwilling to do that piecemeal.

You should also note the companions of type-parametric case classes don't (can't) extends FunctionN, either.

So I'm afraid that the status quo will have to remain.

[scabug]

@refried said:
Hmm... Yeah, I hadn't noted that. Maybe removing it from the auto-generated companions is the best choice, for symmetry. But, binary compatibility.

[scabug]

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

[scabug]

@dwijnand said:
Shouldn't this be closed as a strict duplicate of SI-3664?