Moving from VVT to the L-world value types (LWVT)

[John Rose]

On Feb 13, 2018, at 8:39 PM, Srikanth <srikanth.adayapalam at oracle.com> wrote:
> 
> Instead of a modifier to request flattenable fields, I have an almost working version in my workspace
> that introduces and uses a new annotation java.lang.Flattenable (alongside, @Deprecated, @FunctionalInterface, @Override, @SafeVarargs, @SuppressWarnings ...)
> 
> Modifiers bring in issues around context sensitive keywords, annotations are cleaner IMO.
> 
> I will be pushing this to the branch soon. Let me know if there is a strong reason to prefer a modifier at the prototyping stage itself.

(Late response, but with something I want to put on the table.)

For the record, I prefer a modifier, but one named like __ByValue, so that
it is clear that the syntax is temporary and will go away.  Using an annotation
is OK too, but has the downside of looking permanent when it may not be.

(I realize that javac code complexity is an issue also.  But there are already
code paths to handle quasi-modifiers, so adding more should be just
incremental effort, right?)

A field annotation that affects the load sequence and allowed range of
field values (@Flattenable) is probably too "semantic" to fly as an annotation.
Annotations are *not* allowed to affect base semantics of a Java program.
Of course we *are* changing base semantics, so there is a certain gray
area here, but in the end it would be a bad move if the meaning of a
Java program hinged on the presence or absence of @Flattenable
on some field.  Thus @Flattenable seems temporary, and __Flattenable
would be just as temporary but more obviously so.

— John