Terminology update: primitive objects
brian.goetz at oracle.com
Wed Oct 7 15:30:24 UTC 2020
> 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.
More information about the valhalla-spec-observers