Null-restricted types: Why so complicated?

[John Bossons]

Hi all,

Maybe I am missing something, but the proposal seems to be trying to do too
much.

Specifically: Why not simply provide that appending ! to a type
specification for an object (field, array element, or parameter) means that
that the object is not only null-restricted but also never zero and
necessarily non-atomic unless small?

Why complicate the specification with an implicit constructor that a
developer will never explicitly invoke? Why permit a developer to 'opt in'
to non-atomic?

Sure, that means trying to read a zero value triggers a NPE. That just
means that a type that can legitimately have a zero value cannot be
specified as null-restricted, since a zero value (e.g. a {null, null} Name)
is the equivalent of a null unrestricted value object. Why go beyond that?
If a non-null zero value is possible, the type cannot be null-restricted
and so can only be an unrestricted JEP 401 value type. End of story.

With respect to non-atomic, what is new? Yes, unexpected  instances may
occur without synchronization if the object is larger than the word size of
the implementation. Why do we need to extend a LooselyConsistentValue
interface to know/permit that?

Can we not keep this 'simple' (if that word has meaning in this context)?
What am I missing?

John


-- 
Phone:  (416) 450-3584 (cell)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240118/d34deb25/attachment.htm>