You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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.
@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?
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.