Unsoundness from overriding vals

[howtonotwin]

Tested on Dotty 3.2.0 and 3.2.1-RC2 (both via Scastie). What it says on the tin: overriding a val basically makes paths containing that val unstable. I searched the Dotty issue tracker for this issue and didn't find it, but I was expecting that a (serious?) soundness failure would be there. So this might be a duplicate.

Code

trait X {
  type T
  def process(t: T): Unit
}

class Z(val x: X, val t: x.T) {
  def process(): Unit = x.process(t)
}
class Evil(x1: X, x2: X, t: x1.T) extends Z(x1, t) {
  override val x: X = x2 // breaks connection between x and t
}
// alarm bells should be ringing by now

// taking it to its conclusion...
object x1 extends X {
  override type T = Int
  override def process(t: T): Unit = println("Int: " + t)
}
object x2 extends X {
  override type T = String
  override def process(t: T): Unit = println("String: " + t)
}
new Evil(x1, x2, 42).process() // BOOM: basically did x2.process(42)

Output

No compiler error, and a ClassCastException when run.

Expectation

Compiler error of some kind.

[odersky]

Good point. val overriding has been eyed with unease for a long time, but the objections were mostly about the weird initialization behavior. This might be the final straw to disallow it altogether.

[odersky]

I tried to construct a similar unsoundness example using just member val overriding (no val parameters) but failed. It would be good to find out whether that's just my lack of imagination or indeed it's necessary to have an overridden val parameter to exhibit the unsoundness.

[abgruszecki]

For what it's worth, I took a look at this issue and I also can't find an example where a similar issue occurs without using val parameters. It seems that the real problem is allowing Evil to initialize x twice.