Could the idea of null-default inline classes be revisited?
romanowski.mateusz at gmail.com
Wed May 6 17:29:48 UTC 2020
The idea of null-default value types was raised years ago , however, I
believe it was dropped.
Considering that one of the reasons for Project Valhalla was, I believe,
not to have to choose between using safe abstractions (validating
constructor) and flat memory layout, replacing unsafe fields (ie.
firstName:Ljava/lang/String;, lastName:Ljava/lang/String;) with safe inline
value (ie. person:Qpkg/Person;) that wrap, should be easy without
surprising average developer.
Unfortunately, as Person.default cannot model real person, the developer
needs to learn new idiom for *some* inline types (comparing to default
value instead of null check) and learn that instanceof/cast no longer
rejects all impossible values.
Also, if generalizing the idea of migration of primitive type and its
wrapper class  into value and reference projection, we might consider
If void becomes alias for value projection java.lang.void and
java.lang.Void is its reference projection, then Void value set consists of
void.default and null. This would be a paradox, unless void.default becomes
I think that those might be reasons for introducing L-envelope-using 
null-default inline types/classes.
Are there any chance for having vulls?
More information about the valhalla-dev