<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">OK, let's say for sake of
argument that "well, that's what you opted into." Non-atomic
means no one can count on cross-field integrity; don't select
non-atomic if you have invariants to protect. OK fine. And
let's flip over to what T! means. <br>
<br>
Let's say that T! is a restriction type; it can take on the
values of T, except for those prohibited by the restriction "t
!= null". So, what is the default value of `String!`? <br>
<br>
For locals, it's pretty clear we don't have to answer, because
locals cannot be accessed unless they are DA at the point of
access. But for fields, we have a problem -- and for arrays, a
bigger one. We can try to require that fields have
initializers, but there are all sorts of situations in which a
field can be read before its initializer runs. And arrays are
much worse. <br>
<br>
Which I think connects back to your question about "are we
throwing out the baby with the bathwater when we choose to
encapsulate the whole type rather than just its use in fields or
array components" -- that `String!` is a type that we can really
only use in locals, parameters, and return types, but not in
fields or array components. !!!! Didn't see that connection
coming, though I guess I should have. (I'm sure John did.) <br>
<br>
So one possible perverse answer here -- one that you probably
hate -- is that we *can* spell .val as !, but then ! in fields /
array components are restricted to classes that have a good
default -- and that excludes all identity classes. <br>
<br>
I swear I didn't think that's where this mail was going to end
up. <br>
</font></font><br>
<div class="moz-cite-prefix">On 6/15/2022 2:10 PM, Kevin Bourrillion
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAGKkBktygkVywkd0XQmPGhMpix_8=Gc34Sqy1oe0KHvSV17Pow@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">On Wed, Jun 15, 2022 at 10:51 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">brian.goetz@oracle.com</a>>
wrote:<br>
</div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr"><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div> - If we spelled .val as !, then switching from P[] to
P![] not only prohibits null elements, but changes the
layout and _introduces tearing_. Hiding tearability
behind "non-null" is likely to be a lifetime subscription
to Astonishment Digest, since 99.9999 out of 100 Java
developers will not be able to say "non-null, oh, that
also means I sacrifice atomicity." </div>
</blockquote>
<div><br>
</div>
<div>Well, that's what you opted into when you... wait a
minute...</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>The link you probably want to attack is this last one,
where you are likely to say "well, that's what you opted
into when you said `non-atomic`; you just happen to get
atomicity for free with references, but that's a bonus." <br>
</div>
</blockquote>
<div><br>
</div>
<div>Your Kevin's Brain Emulator has gotten pretty decent over
time... check whether the next things it said were these
(probably so):</div>
<div><br>
</div>
<div>A good clean Basic Conceptual Model For Novices is
allowed to have a bunch of asterisks, of the form "well, in
$circumstance, this will be revealed to be totally false",
and that's not always a strike against the model. How do we
discern the difference between a good asterisk and a bad
one? How common the circumstance; how recognizable as <i>being</i> a
special circumstance; how disproportionate a truth
discrepancy we're talking about; etc.</div>
<div><br>
</div>
<div>I know I've said this before. If I'm in a class being
taught how this stuff works, and the teacher says "Now
unsafe concurrent code can break this in horrible ways, and
in $otherClass you will learn what's really going on in the
presence of data races" ... I feel fully satisfied by that.
I know I won't get away with playing fast and loose with The
Concurrency Rules; I'm not advanced enough and might never
be. (Many people aren't but <i>don't </i>know it, and
therein lies the problem, but do we really have much power
to protect such people from themselves?)</div>
<div><br>
</div>
<div>I could be wrong, but I suspect this kind of viewpoint
might be more common and respected in the wider world than
it is among the rarefied kind of individuals who join expert
groups, no offense to anyone here meant. You're always going
to see all the details, and you're always going to <i>want</i> to
see all the details. The general public just hopes the
details stay out of their way. When they don't, they have a
bad day, but it doesn't mean they were better served by a
complex model that tried to account for everything.</div>
<div><br>
</div>
<div><br>
</div>
</div>
-- <br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px
0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin
Bourrillion |</span><span style="border-width:2px 0px
0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java
Librarian |</span><span style="border-width:2px
0px
0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google,
Inc. |</span><span style="border-width:2px 0px
0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">kevinb@google.com</a></span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>