docs

Author: adriaanm

src/compiler/scala/tools/nsc/transform/Fields.scala

@@ -14,19 +14,41 @@ import symtab.Flags._
   *
   * For traits:
   *
-  *   - Namers translates a definition `val x = rhs` into a getter `def x = rhs`
+  *   - Namers translates a definition `val x = rhs` into a getter `def x = rhs` -- no underlying field is created.
   *   - This phase moves `rhs` into a block nested under the template's local dummy.
   *     If the value is memoized (stored), the block's final expression assigns the value to the val,
   *     and the val itself is left without a rhs.
-  *     (Dotty uses a method `x$compute` instead of a block, which is used in the constructor to initialize the val.
-  *      It also unifies strict and lazy vals, in that the RHS is lifted to a method for both.)
-  *     If the value of the rhs is a literal or unit, it is not stored and the final expression of the block is ().
-  *     The val then retains this statically known value as its rhs, with its side-effects still lifted to the block.
-  *   - This phases also synthesizes accessors and fields for any vals mixed into a non-trait class.
-  *   - Constructors moves the expressions in the template into the constructor,
-  *     which means it will initialize the values defined in this template.
+  *     If the value of the rhs is a literal (ConstantType), it is not stored and the final expression of the block is ().
+  *     The val then retains this statically known value as its rhs.
+  *     (We could extend this to other fields that needn't be stored,
+  *      but would still need to lift their side-effects to the block.
+  *      We're mostly to set up for this, and experimented with doing this for Unit-typed vals.
+  *      No longer storing and writing to fields is too much of a a change in semantics.
+  *      Mainly regarding the memory model -- visibility of writes across threads etc would change.)
+  *   - This phase also synthesizes accessors and fields for any vals mixed into a non-trait class.
+  *   - Constructors moves the statements in the template into the constructor,
+  *     which means it will initialize the fields defined in this template (and execute the corresponding side effects).
   *
-  * Runs before erasure (to get bridges), but before lambdalift/flatten, so nested functions/definitions must be considered.
+  * Runs before erasure (to get bridges), and thus before lambdalift/flatten, so that nested functions/definitions must be considered.
+  *
+  * TODO:
+  *   - remove backwards compatibility hacks to complete migration to Java 8-encoding of traits
+  *   - minimize introduction of new flag bits?
+  *   - ...
+  *
+  * In the future, would like to get closer to dotty, which lifts a val's RHS to a method `x$compute` instead of a block,
+  * which is used in the constructor to initialize the val.
+  * This makes for a nice unification of strict and lazy vals,in that the RHS is lifted to a method for both,
+  * with the corresponding compute method called at the appropriate time.)
+  *
+  * In the even longer term, I agree with @DarkDimius that it would make sense to
+  * hide the difference between strict and lazy vals. All vals are lazy,
+  * but the memoization overhead is removed when we statically know they are forced during initialiation.
+  * We could still expose the low-level field semantics through `private[this] val`s.
+  *
+  * In any case, the current behavior of overriding vals is pretty surprising.
+  * An overridden val's side-effect is still performed.
+  * The only change due to overriding is that its value is never written to the field (the overridden val's value is, of course).
   */
 abstract class Fields extends InfoTransform with ast.TreeDSL with TypingTransformers {