vals in a nested singleton object may be initialized to null

[matil019]

Compiler version

3.0.0, 3.1.3, 3.2.0 and 3.2.2-RC1-bin-20221006-a6a3385-NIGHTLY

Minimized code

final case class Foo(name: String)

object Foo {
  object Foos {
    val Name1 = Foo("Apple")
    val Name2 = Foo("Banana")
    val Name3 = Foo("Cherry")
    // Using explicit `new`s prevents the issue
    // val Name1 = new Foo("Apple")
    // val Name2 = new Foo("Banana")
    // val Name3 = new Foo("Cherry")
  }

  val allFoos: Seq[Foo] = {
    import Foos._
    Seq(Name1, Name2, Name3)
  }
}

object Main {
  def main(args: Array[String]): Unit = {
    println(Foo.Foos.Name1)
    println(Foo.allFoos)
    // Accessing in the reverse order (or not accessing Name1 at all) prevents the issue
    // println(Foo.allFoos)
    // println(Foo.Foos.Name1)
  }
}

Output

Foo(Apple)
List(null, null, null)

Expectation

The output should be:

Foo(Apple)
List(Foo(Apple), Foo(Banana), Foo(Cherry))

Replacing any of the commented part of the program above prevents the issue. Also, Scala 2.13.9 produces the expected output without any modification. So, this is a behavior change between 2.13 and 3.

[som-snytt]

Scala 2 lacks "universal apply" and rewrites the "case apply" to "new" in refchecks. I think these init issues are a fact of life?

I would expect (?) -Ysafe-init to tell me something.

Also for the record, I can never remember -Ysafe-init. I start with -Ycheck-init and then spend five minutes searching the output of -Y and sometimes -X too.

[matil019]

Unfortunately, -Ysafe-init has no effect (no compilation warnings/errors).

[matil019]

It turned out that Scala 2.13 has the same problem when a handmade factory method is used instead:

final case class Bar(name: String)

object Bar {
  object Bars {
    val Name1 = Bar.make("Apple")
    val Name2 = Bar.make("Banana")
    val Name3 = Bar.make("Cherry")
  }

  def make(name: String): Bar = Bar(name)

  val allBars: Seq[Bar] = {
    import Bars._
    Seq(Name1, Name2, Name3)
  }
}

object Main2 {
  def main(args: Array[String]): Unit = {
    println(Bar.Bars.Name1)
    println(Bar.allBars)
  }
}

Output (2.13.9):

Bar(Apple)
List(null, null, null)

I was not able to find an existing bug report for this in scala/bug.

[som-snytt]

Sample Scala 2 issue

scala/bug#3342

[liufengyun]

Related: #11262 #9176

Currently -Ysafe-init is not capable of handling static objects.

[bertlebee]

@odersky how is this not a bug? surely this is not the expected behaviour. I guess fixing a bug would be an enhancement, but that doesn't mean this isn't broken behaviour.

[som-snytt]

@robmwalsh maybe a 3rd party linter could say, "This is the expected behavior which you may not have expected."

(Personally, I am on the fence. I'd prefer the language lock down cases which are obvious from a "platform" perspective.)

[odersky]

@robmwalsh It is very much the expected behavior according to the rules for initialization. The reason Scala-2 does not have the behavior is that Scala-2 silently rewrites a case class apply into a constructor call, thereby skipping the initialization of the enclosing object. This is surprising behavior, because it changes initialization order in unforeseen ways, even though it happens to be beneficial in this case.

So the only thing we should do is diagnose better that this is not initialization safe.

[bertlebee]

@robmwash It is very much the expected behavior according to the rules for initialization. The reason Scala-2 does not have the behavior is that Scala-2 silently rewrites a case class apply into a constructor call, thereby skipping the initialization of the enclosing object. This is surprising behavior, because it changes initialization order in unforeseen ways, even though it happens to be beneficial in this case.

So the only thing we should do is diagnose better that this is not initialization safe.

Fair enough I guess. These initialization shenanigans are going to be a real sticking point for new users. I'm very used to the behavior from scala 2 which has never caused me any real trouble. I stumbled across this issue after getting stung by #16456 (the 2nd stack overflow case) and it's cost me another couple of days of digging through the compiler trying to figure out the cause. Diagnosing better would very much be appreciated. I've raised #16593 which will help with crash diagnosis in general, though I'm not sure about this one in particular since it will still compile (I don't actually think it should compile if it's unsound)

[liufengyun]

So the only thing we should do is diagnose better that this is not initialization safe.

FYI, @olhotak and I are still investigating a solution to this problem (One of previous attempts #12698). The challenge here is to have a solution that is simple, expressive, fast, and sound. If things go smoothly, we will propose a PR in the coming month(s).

[liufengyun]

This can now be checked with the experimental option: -Ysafe-init-global.