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 class." (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.) — John On Apr 8, 2019, at 1:45 PM, Brian Goetz <brian.go...@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. >
