Typed variants of primitives

[Jesper Steen Møller]

> On 2 Dec 2020, at 16.17, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> 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?)  
> 

Agreed. And since we can't avoid tearing without a heavy overhead, we probably shouldn't bother with the data race either.


> 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.  
> 

Doable is good - and even better with a way do specify "don't do this" where we can: You can restrict access to a default constructor, or deprecate it. Could we do something similar with .default?

-Jesper