Update FAQ on initialization order #3017
Conversation
|
|
||
| **-Xcheckinit**: Add runtime check to field accessors. | ||
| The [`-Ysafe-init` compiler flag](https://docs.scala-lang.org/scala3/reference/other-new-features/safe-initialization.html) in Scala 3 enables compiler warnings for accesses to uninitialized fields: |
There was a problem hiding this comment.
suggest mentioning here that the flag is experimental, like all -Y flags
There was a problem hiding this comment.
That's like saying use it, but don't like use it. How about instead of experimental, we start saying "cutting-edge". Also, experimental has the narrow meaning for dotty that you need a flag and an experimental compiler to use the feature.
There was a problem hiding this comment.
it will also be -Wsafe-init from 3.5
| In Scala 2, the `-Xcheckinit` flag adds runtime checks in the generated bytecode to identify accesses of uninitialized fields. | ||
| The code then throws an exception rather than allowing a `null` (or `0` / `false` in the case of primitive types) to silently appear. | ||
| Note that these runtime checks only test code that is actually exectued at runtime. | ||
| The flag can be helpful to find accesses to uninitialized fields, but it should never be used in production due to its performance overhead. |
There was a problem hiding this comment.
| The flag can be helpful to find accesses to uninitialized fields, but it should never be used in production due to its performance overhead. | |
| The flag can be helpful to find accesses to uninitialized fields, but it should not be used in production due to its performance overhead. |
There was a problem hiding this comment.
"must never", and spoken with Germanic authority. People run debug in production all the time just in case there's a crash, which there always is.
| Using it on the opening example: | ||
| In Scala 2, the `-Xcheckinit` flag adds runtime checks in the generated bytecode to identify accesses of uninitialized fields. | ||
| The code then throws an exception rather than allowing a `null` (or `0` / `false` in the case of primitive types) to silently appear. | ||
| Note that these runtime checks only test code that is actually exectued at runtime. |
There was a problem hiding this comment.
| Note that these runtime checks only test code that is actually exectued at runtime. | |
| Note that these runtime checks only test code that is actually executed at runtime. |
|
@SethTisue I suggest we don't wait for Lukas and definitely don't wait for Seb, who would incur more rounds of nits even pickier than previously surfaced. |
|
|
||
| Constant values are stricter than strict and earlier than early definitions and have even more limitations, |
There was a problem hiding this comment.
Omitting compile-time mechanisms to work around runtime issues seems important. Probably more is available in Scala 3 besides final vals.
Let's also respect that this was the original one-question FAQ. Maybe a minute of silence?
| abstract class A { | ||
| val x1: String | ||
| val x2: String = "mom" | ||
| Note that using multiple lazy vals creates a new risk: cycles among lazy vals can result in a stack overflow on first access. |
There was a problem hiding this comment.
Or dead lock in Scala 3 for thread-safe lazy vals.
| class B extends A { | ||
| val x1: String = "hello" | ||
| final val x3 = "goodbye" | ||
| ### Use a nested object |
There was a problem hiding this comment.
Isn't that basically the same solution as a lazy val?
No description provided.