generic specialization design discussion
john.r.rose at oracle.com
Mon Apr 8 21:55:54 UTC 2019
I like this, FTR.
Note also that inline classes *may* be passed by indirection,
while indirect classes *must*. The inline guys have new
capabilities, plus the old ones.
Why would you *want* to represent an inline-capable class
with an indirection? Good question. Any of the following
can be a reason to do so:
- use via the Object type or an interface (they are indirect)
- signature compatibility with existing APIs (Optional, LDT)
- atomic updates (volatile variables)
- forced nullability of null-hostile classes (ZDV?)
- permission to load the class later (breaking bootstrap cycles)
- option to translate recursive value types (requires an indirection)
- fine control over object layout (when you prefer sharing to flattening)
- fine control over object API (when you prefer heap buffering to scalarization)
These are all factors we take for granted with Java references today.
They become optional with inline classes.
An "inline class" would more precisely be an "inlinable class",
but doesn't it feel overly pedantic to use the precise term?
So I like "inline class", with the caveat that the first five
minutes of training requires somebody to say something
like, "An inline class can flattened in memory or scalarized
across APIs. It can also be manipulated indirectly like any
(Note that C++ does something vaguely similar: A function
marked "inline" can be used indirectly, by taking its address.
The "inline" modifier does not *forbid* indirect use.)
On Apr 8, 2019, at 1:45 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> And the opposite of “inline” is “indirect”. ref, interface, and null-adjoined types are _indirect_. Indirect classes are passed by pointer, do not get flattened, get erased, are nullable.
More information about the valhalla-spec-observers