Confusing semantics of uninitialized `final val` containing literal constants

Compiler version

3.0.0

Minimized code

class Creature {
  val range: Int = 10
  println(range)
}

class Ant1 extends Creature {
  override final val range = 2
}

/*final*/ class Ant2 extends Creature {
  override /*final*/ val range: Int = 2
}

object Test extends App {
  new Ant1
  new Ant2
}

Output

➜  snips scala question.scala
2
0

If Ant2.range is final, it is inlined (questionably):

➜  snips scala question.scala
2
2

If class Ant2 is final, non-final range is not inlined.

Expectation

It works as described in the one-question FAQ

Asked on gitter in Scala 2 context.

[liufengyun]

Compile with -Ysafe-init, we get:

sbt:scala3> scalac -d out -Ysafe-init examples/i12570.scala

-- Warning: examples/i12570.scala:7:21 -----------------------------------------
7 |  override final val range = 2
  |                     ^
  |                     Access non-initialized value range. Calling trace:
  |                      -> class Ant1 extends Creature {	[ i12570.scala:6 ]
  |                       -> val range: Int = 10	[ i12570.scala:2 ]
  |                        -> println(range)	[ i12570.scala:3 ]
-- Warning: examples/i12570.scala:11:25 ----------------------------------------
11 |  override /*final*/ val range: Int = 2
   |                         ^
   |         Access non-initialized value range. Calling trace:
   |          -> /*final*/ class Ant2 extends Creature {	[ i12570.scala:10 ]
   |           -> val range: Int = 10	[ i12570.scala:2 ]
   |            -> println(range)	[ i12570.scala:3 ]
2 warnings found

The checker currently does not optimize for constant folded fields. It seems to be a good choice to defend against subtle code that employs constant folding and “violates” initialization semantics.

[sjrd]

I believe we can reconcile all these apparently conflicting requirements using the following reasoning:

• Accessing a val before it has been defined, in the initialization order, is unspecified behavior. It may return any value inhabiting the val’s type (or an invalid null with the explicit nulls).
• The initialization checker reports any such use as invalid, since the behavior of the program would be unspecified in that case.
• Knowing that, the compiler is free to optimize vals with literals as defs, because it does not change the semantics of any program that stays within specified behavior. It may change the effective behavior of a program that triggers unspecified behavior, but it has the right to do so because, well, it’s unspecified.

That means that:

• The init checker should not be changed; it is correct to flag any use-before-initialization as unspecified behavior.
• The compiler can optimize final vals and vals in final classes.