generic specialization design discussion

[Brian Goetz]

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.goetz at 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.goetz at oracle.com <mailto:brian.goetz at 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.goetz at oracle.com <mailto:brian.goetz at 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 <kevinb at google.com <mailto:kevinb at 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.goetz at oracle.com <mailto:brian.goetz at 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.rose at oracle.com <mailto:john.r.rose at 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. | kevinb at google.com <mailto:kevinb at google.com>
>> 
>