Could the idea of null-default inline classes be revisited?

[Mateusz Romanowski]

Hi John,
Thanks for the answer.

I have missed the idea of having both through manual transcoding in API
points. However, since accessibility of V.val and V.ref is same, I would
not export V and instead export another type sealed to permit just V.

Nonetheless, thanks for leaving the issue open to become a possible future
extension - I guess there are a few letters remaining to declare new
envelope if a disjoined namespace was needed.

Thanks,
Mateusz

On Wednesday, May 6, 2020, John Rose <john.r.rose at oracle.com> wrote:
> On May 6, 2020, at 12:46 PM, John Rose <john.r.rose at oracle.com> wrote:
>
> For now, the choice is pretty straightforward:  If you
> need null as a value in a variable of type V, use V.ref.
> If you need flatness in the variable, use V.val.  Choose
> one.
>
> P.S. If you need both, encapsulate the field as a V.val
> and transcode between V.default and (V.ref)null in
> access methods and constructors.  If you need naked
> fields *and* flatness *and* null, you are still out of luck.
> Sadly, record types won’t help with this, thought perhaps
> there’s some limited call for boxing/unboxing relations
> between a record’s internal and external field types;
> that’s another can of worms.  Use Java’s class-based
> data abstraction!