Revisiting default values

[Stephen Colebourne]

On Tue, 14 Jul 2020 at 19:59, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> If LocalDate becomes the inline class, then 'new LocalDate[10]' will be
> an array of inline instances, not references.
> At least that was the expectation when labeling LocalDate as a value class.
> And they should be initialized to a value that is provided by or
> consistent with one of the constructors.

My view is that the only acceptable default for LocalDate is
(conceptually) null. But it is also my view that this should not
prevent it from being an inline class.

The complete value set of LocalDate consists of all valid dates plus
null. Conceptually, this isn't the null reference as we currently know
it, but an instance of the LocalDate inline type that can be treated
as null at the language level. ie.a different kind of null but one
that cannot be distinguished as different at the language level. Thus
new LocalDate[10] will continue to be full of nulls, but they would be
inline instance LocalDate nulls, not null references.

Thus you have:
a) values where "all bits zero" has meaning as a default - int,
Long128, Optional
b) values where "all bits zero" is treated as null - LocalDate, Currency, Money
I struggle with any Valhalla outcome where (a) is significantly more
performant/optimised than (b), because that would push developers to
expose inappropriate default values. We'd end up with a lot more of
Kevin's 1970-01-01 oddities (such as a default of Currency XXX or
Money XXX 0). As such, I'm unconvinced by the current .ref/.val
approach to solving this.

My desired semantics are exactly as today:
 var a = new LocalDate[10];
 assert a[0] == null; // OK
 a[0].getDayOfMonth(); // NPE
but with the memory storage of the array being flattened/inlined.

This works for LocalDate because "all bits zero" is not in use and
free to be interpreted as "null". The language/JVM would need to
guarantee this for all nullable inline types (perhaps by checking the
bits are not all zero at the end of the constructor).

Any attempt to say LocalDate has a default (or that LocalDate.val has
a default) seems doomed to failure, even if it is just to say the
default is invalid. The last thing I'd want to see is an "undefined"
concept added to Java that is similar to null but different.

Dan's Option J is supposed to capture this direction.

Stephen