Automatic override of reapplied case class arguments?

Language Design
1

Consider the following example

class Foo(val arg : Int) 
case class FooCC(arg : Int) extends Foo(arg)

This example would fail, and requires and override for arg. So to solve it we can either do:

abstract class Foo {
  val arg : Int
} 
case class FooCC(arg : Int) extends Foo(arg)

or

class Foo(val arg : Int) 
case class FooCC(override val arg : Int) extends Foo(arg)

I always found this extremely annoying, and I’m wondering if the compiler can realize that the same argument is reapplied onto itself and automatically use an override.

3 Likes
3

One question is: how often does this happen? In normal code for me it is once in a blue moon, so the override val isn’t a huge hardship

One exception to this is Mill build definitions, where almost every definition is an override, and we have a small compiler plugin to insert the override flags automatically to avoid syntactic boilerplate. But that’s not the case in most “normal” Scala code I come across

Another thing is that overriding concrete vals is always a bit dangerous - it can cause NPEs (or worse) if the val is used in the superclass constructor - so making it a bit awkward seems like a reasonable thing to do.

3 Likes
4

I’ve seen this pattern most frequently when defining GADTs, but working around it by setting up the original as a def or just putting in the override val has never felt particularly onerous to me