<div dir="ltr">Hi all,<div><br></div><div>Maybe I am missing something, but the proposal seems to be trying to do too much. </div><div><br></div><div>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? </div><div><br></div><div>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?</div><div><br>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.</div><div><br>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?</div><div><br>Can we not keep this 'simple' (if that word has meaning in this context)? What am I missing?</div><div><br></div><div>John</div><div><br></div><div><br></div><div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Phone:  (416) 450-3584 (cell)</div></div></div></div>