lazy statics design notes

[John Rose]

On Feb 28, 2019, at 4:54 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> 
>> The limitation against T.default can be spun, to many users, as a common sense
>> error check, against uninitialized variables.  To more curious users, it can be spun
>> as a conscious reservation for efficient implementations.
> 
> This is justifiable for (most) ref types, but what about numeric types?   I can imagine many potentially-expensive computations that could reasonably sum to zero.  (And as you point out, the smaller the range, the more silly this gets, ending with boolean.)  So if we're going to have this restriction, it should be restricted to class types, and the recommended workaround be some sort of Optional or box.  And given that not all values will be null-default, it rules out any value types for which the zero answer is a reasonable answer.  I think this edge is sharper than it looks.

What I want here can be obtained by forbidding nulls, specifically, for
nullable types, and then doing something different for non-nullable types.

A translation strategy could deal with non-nullable types (like boolean)
by using condy for statics and some other mechanism for non-statics,
such as desugaring the type of the field to a reified Optional<int>.

Would that have fewer sharp edges?

Wrapping an Optional around every nullable non-static reference is
conceivable but that seems to be add a disruptive number of indirections,
and also Optional itself excludes nulls.  We've made the no-null
policy decisions for Optional; let's benefit from it for lazies.

— John