`final val`s that is implemented with a literal constant false positive in initialization checker

Compiler version

3.0.0

Semantics of final val with literal constants

All final vals that is implemented with a literal constant do not generate a field in the bytecode. Their accessors simply return the value and the field is elided.

This optimization makes the bytecode smaller and helps the JVM JIT to inline this value.

Initialization checker

The initialization checker is currently unaware of how code is generated for these fields. It believes that we do generate the fields and that there is a potential for uninitialized values. The reality is that these will always be seen as initialized as they always return the correct value.

We need to teach the initialization checker about this field encoding.

[dwijnand]

Does everyone agree with @sjrd, (from https://github.com/lampepfl/dotty/issues/12570#issuecomment-857805134) that

The init checker should not be changed; it is correct to flag any use-before-initialization as unspecified behavior.

?

[olhotak]

It appears that the semantics that the compiler should implement are still being debated in https://github.com/lampepfl/dotty/issues/12570.

Once the semantics are decided there, my opinion is that the initialization checker should follow the actual semantics as closely as possible rather than trying to also be a linter, trying to enforce a “better”, “cleaner” semantics than the compiler actually implements. If something is safe but only due to ugly hacks, I think the initialization checker should not report it unsafe. Many use the type checker as an oracle to improve their understanding of the specification of the type system. Similarly, many will use the initialization checker to improve their understanding of the details of initialization. Inconsistency between the init checker and the actual init semantics will be confusing to that understanding.

It sounds like the #12570 is converging towards preserving the semantics of final for backward compatibility with Scala 2 and Java but preferring inline to better express the intended semantics. In that case, there could be a lint-style deprecation/migration warning, separate from the initialization checker, that suggests the use of inline instead of final.

In summary, as a general rule, I think the initialization checker should match actual semantics as closely as possible and lint/style warnings should be separate and marked as such without suggesting that a runtime error will occur.