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
We disallow overriding of val parameters, which fixes the soundness problem
discovered in #16092.
There is one exception: If a val parameter is overridden by another val
parameter that can be shown to always have the same value (in the sense
established by Paramforwarding.inheritedAccessor). This exception is needed
to make a not-so-uncommon pattern of case class inheritance go through.
Example:
abstract class A(val x: Int)
case class B(override val x: Int) extends A(x)
case class C(override val x: Int) extends A(x)
case object D extends A(0)
Here, the `override val`s are necessary since case class parameters are always vals,
so they do override the val in class A. It should be noted that the override val generates
a second field, so this not a very efficient representation. A better design would be
to use an abstract field in `A`:
abstract class A { val x: Int }
case class B(val x: Int) extends A
case class C(val x: Int) extends A
case object D extends A { val a = 0 }
But that causes slightly more work for cases as in D. Which seems to be why the first pattern
is sometimes used. It might be desirable to disallow the second pattern, but that would cause
quite a bit of migration hassle since it requires synchronized changes at several places of
a class hierarchy.
0 commit comments