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.
> On Apr 8, 2019, at 4:20 PM, Brian Goetz <brian.go...@oracle.com> wrote: > > Refining this: > > - inline classes are inlinable (duh) > - reference classes, interfaces, and nullable-projections of zero-default > inline classes are not inlinable > > (We later use these to say: Instantiation of generics with non-inlinable > types are erased.) > > That seems not terrible, except for the “nullable projection of zero-default > inline classes” part, which is both a mouthful and has “inline” in it. > Perhaps calling these something like “null-adjoined types” (to reflect the > fact that we’re cramming a null into a type whose value set doesn’t naturally > contain null) makes that slightly better. So: > > - inline classes are inlinable > - reference classes, interfaces, and null-adjoined types are not inlinable > > > > >> On Apr 8, 2019, at 3:06 PM, Brian Goetz <brian.go...@oracle.com >> <mailto:brian.go...@oracle.com>> wrote: >> >> A related issue is that we want a word for describing which types are >> routinely flattened in layouts, and specialized in generics (the criteria >> are the same). Currently: >> >> - References and nullable projections of values (V?) are erased and not >> flattened >> - Values (zero-default and null-default) are specializable and flattenable >> >> (This thread is for terminology; if you have questions about the above >> claims, make a new thread, or better, wait for the more detailed writeup >> explaining why this is.) >> >> We need words for these two things too. >> >>> On Apr 8, 2019, at 2:58 PM, Brian Goetz <brian.go...@oracle.com >>> <mailto:brian.go...@oracle.com>> wrote: >>> >>> Yes, that’s a promising direction. And this is surely the motivation why >>> the C# folks picked “struct”; they wanted to carry the connotation that >>> this is a structure that is inlined. Problem is, the word “struct” is >>> already so heavily polluted by what it means in C. So perhaps something >>> like: >>> >>> inline class V { … } >>> >>> This says than a V can be inlined into things that contain a V — other >>> classes and arrays. It also kind of suggests that this thing has no >>> intrinsic identity. >>> >>> A possible downside of this choice is that one might mistake it for meaning >>> “its methods are inlined”. Which is actually a little true, in that the >>> methods are implicitly static and therefore more amenable to dynamic >>> inlining. So that might actually be OK. >>> >>> Others? >>> >>>> On Apr 8, 2019, at 2:25 PM, Kevin Bourrillion <kev...@google.com >>>> <mailto:kev...@google.com>> wrote: >>>> >>>> I'd suggest the name should in some way allude to the inline/compact/flat >>>> memory layout, because that is the distinguishing feature of these new >>>> things compared to anything else you can do in Java. And it is what people >>>> should be thinking about as they decide whether a new class should use >>>> this. >>>> >>>> >>>> On Mon, Apr 8, 2019 at 10:02 AM Brian Goetz <brian.go...@oracle.com >>>> <mailto:brian.go...@oracle.com>> wrote: >>>> The slide deck contains a list of terminology. I’d like to posit that the >>>> most confusion-reducing thing we could do is come up with another word for >>>> value types/classes/instances, since the word “value” is already used to >>>> describe primitives and references themselves. This is a good time to see >>>> if there are better names available. >>>> >>>> So for this thread only, we’re turning on the syntax light to discuss what >>>> might be a better name for the abstraction currently known as “value >>>> classes”. >>>> >>>> >>>> >>>> > On Mar 29, 2019, at 12:08 PM, John Rose <john.r.r...@oracle.com >>>> > <mailto:john.r.r...@oracle.com>> wrote: >>>> > >>>> > This week I gave some presentations of my current thinking >>>> > about specializations to people (from Oracle and IBM) gathered >>>> > in Burlington. Here it is FTR. If you read it you will find lots >>>> > of questions, as well as requirements and tentative answers. >>>> > >>>> > http://cr.openjdk.java.net/~jrose/pres/201903-TemplateDesign.pdf >>>> > <http://cr.openjdk.java.net/~jrose/pres/201903-TemplateDesign.pdf> >>>> > >>>> > This is a checkpoint. I have more tentative answers on the >>>> > drawing board that didn't fit into the slide deck. Stay tuned. >>>> > >>>> > — John >>>> >>>> >>>> >>>> -- >>>> Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com >>>> <mailto:kev...@google.com> >> >
