Typed variants of primitives

[Brian Goetz]

You can try, but you can only succeed partially.

The essential problem you are trying to avoid is observing an 
uninitialized variable.  The JVM provides a base level of safety by 
ensuring that if you observe an uninitialized variable (fields and array 
elements), you get a well-defined default (which conveniently happens to 
be all zero bits) rather than whatever garbage bits were left over from 
last night's party. The special reference "null", with its fail-fast 
behavior, is a good default for object references, because if you try to 
use it, you find out quickly.

Languages can try to make this harder, but beyond a certain point, each 
additional increment gets expensive (e.g., should we try to prevent the 
default value from being observed through a data race?)

For example, we already require final fields to be DU at the end of the 
constructor.  We could engage a similar sort of type checking for fields 
of inline classes that have no good default, but (a) this might be too 
restrictive, (b) what about data races, and (c) it doesn't give us much 
to solve the harder problem which is arrays.

But we can't ban arrays of NGDV inlines; ArrayList needs them. So "trust 
the library" quickly degenerates to "trust everyone", which is to say: 
pick 1972 as the default, and let the chips fall where they may.  This 
is doable, but not so great.





On 12/2/2020 9:54 AM, Jesper Steen Møller wrote:
> Hi list
>> On 2 Dec 2020, at 15.31, Brian Goetz <brian.goetz at oracle.com> wrote:
>>
>> The topic of "inline classes with no good default" is indeed a thorny one, and we don't yet have a good set of recommendations here.  Possible moves include:
> Rhetorically: So why is it really that we need default values for inline classes?
>
> I understand it at the VM level: So that for instance ArrayList<T> eventually can allocate an array of inline T to some capacity, fill it with '.default', and manage the "liveness" of the default values at some higher level, without having to encode the initialized'ness of the array contents.
>
> For raw arrays in Java, there is no "library", which leaves us with "new Year[7]" giving us seven years of tribulation.
>
> So at the VM-level, we need this to do what we want to do.
>
> But at the language-level, couldn't we handle this differently somehow by marking inline classes which have undesirable defaults, and then issuing warnings in case anyone uses it (implicitly or explicitly)?
> I do realize you'd still need one of:
>
>> 2.  Pick an arbitrary default (Jan 1, 1972.)
>> 3.  Invent a sentinel, try to make using it fail-fast (like a new kind of null), and make users check it (which they'll forget to do.)
> to complete the semantics, but you'd still avoid solutions 1 and 4 and force more code to go through the restricted types "barrier to entry".
>
> For comparison:
> C++ and Rust have similar issues.
> While they both support types without defaults at the language/type system level, they solve the collection-over-array challenge by trusting the library.
>
> -Jesper
>