Terminology update: primitive objects

[Brian Goetz]

>  From a user perspective, will the new terms encourage the right mental
> model for when value types get flattened (or not)?  As an EG, early on
> we spent a lot of time discussing "flattened" vs "flattenable" and
> trying to guide users to the view that this is a VM-level decision and
> not a guarantee.   Does leaning on the "pass by value" inituition undo
> that previous work?

The intent of this taxonomy is indeed to encourage the correct mental 
models (now that we actually understand what the correct mental model is.)

The centerpiece of the current language design is that, for primitive 
classes, there are two ways to "describe" an instance: directly and 
indirectly.  The varying modes of description applies (among others) to 
fields (flattening) and calling conventions (scalarization) and 
variables (does the variable hold a value, or a reference.)  The 
intuition of "by value" and "by reference" is intended to capture all of 
these differences; do you store the value, or a reference to the value?  
Do you pass a value, or a reference to the value?  Is the type of `t` a 
value, or a reference to a value?

As a statically typed language, we capture this distinction by dividing 
between _primitive value types_ and _primitive reference types_ (a form 
of reference type, an existing concept.)  The modifiers "value" and 
"reference" are chosen to evoke "by value" and "by reference", whether 
for passing, storing, or describing.  It took a long time to realize 
this was essentially a forced move, since the value set of interface 
types consists of references to objects, and if we want primitive 
objects to implement interfaces, then there must be a way to describe 
them with references as well as directly.

The reference vs value characterization is semantic, but reasonably 
correlates with expectations about runtime behavior.  Today, with 
reference types, we assume that they will _routinely_ be implemented 
with pointers (and they are), but in some cases, the VM figures out it 
can scalarize or constant fold (and we don't mind).  Similarly, with 
primitive value types, we assume they will be _routinely_ flattened, but 
the ultimate decision is the VMs, and there may be circumstances when 
the VM decides on an indirect representation.  So these intuitions are 
aimed at setting reasonable expectations, but not guarantees.