new lazy val locking scheme

[adriaanm]

see one gotcha in https://github.com/lampepfl/dotty/pull/2276

[SethTisue]

not possible to change in 2.13.x

[smarter]

Why ? It's possible to change the lazy val scheme without breaking binary-compatibility.

[smarter]

Also see https://github.com/lampepfl/dotty/issues/7140 / https://github.com/lampepfl/dotty/pull/6979 for the latest proposal.

[SethTisue]

Adriaan is concerned about other kinds of risk (e.g. around locking) as well as binary compatibility, but sure, we can keep it open.

[SethTisue]

new lazy val implementation recently landed in Scala 3 over at https://github.com/lampepfl/dotty/pull/15296 by @szymon-rd

[lrytz]

@szymon-rd is there a detailed description of the lazy vals new scheme? The list of "Advantages" in https://github.com/lampepfl/dotty/pull/6979 sounds good. But it's definitely a risky thing to touch.

[szymon-rd]

@lrytz The advantages in this ticket are up to date. It also fixed a bug with @transient and simplified overall structure. The multithreaded performance is better too, benchmarks are in the PR. Regarding the risk - I agree that it is significant, but luckily we now have the open community build and we run all the Scala projects and their tests, we also run all the tests containing lazy vals for the new implementation. The scheme itself is included in the comment in the LazyVals transform class, where it is generated.