Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Inconsistent behaviour of case classes with and without an explicit companion object #4808
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.
@retronym said (edited on Sep 19, 2013 7:03:46 AM UTC):
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.
@refried said (edited on Sep 18, 2013 10:56:15 PM UTC):
Are there some stdlib case companions that have Function1-ness that could break? Would their Function1-ness go away?
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.