<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">Quick observation: the default
value of `String!` is less dangerous to allow free, because its
"null", and the user can already freely make nulls. Whereas
the default value of `Instant` is not something the user can get
their hands on, if they can't observe fields of type
`Instant.val` during initialization. So the problem may be less
severe for B1. </font></font><br>
<br>
<div class="moz-cite-prefix">On 6/16/2022 3:16 PM, Kevin Bourrillion
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAGKkBktxmqC0TdyH_fGyfkgSXVmPQY2+BTk+0_WQwKUQgZXXpA@mail.gmail.com">
<div dir="ltr">
<div>On Wed, Jun 15, 2022 at 12:01 PM 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 dir="ltr"><br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div> <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!`? </font></font></div>
</blockquote>
<div><br>
</div>
<div>I'd like to slightly rephrase your question to "What do
we do when we need a default value <i>for</i> `String!`",
because I don't like the framing that suggests that a
default value is an inherent property <i>of a type</i> itself.
(I've no idea what type theorists would say.)</div>
<div><br>
</div>
<div>And we were talking about bucket 2, a "value class with
no good default" so I'll substitute `Instant!` instead of
`String!` for most of this.</div>
<div><br>
</div>
<div>So, what to do when we need a default value for
`Instant!`? I guess "just blow up" is a non-option because
every field has to start off somewhere. So I guess we have
to answer "it's `fromEpochMilli(0)` because it can't be
anything else, but we're going to do what we can to prevent
its users from depending on that fact." Definitely, making
an explicit value type that's nonpublic is a way to do just
that. Is there a more surgical way to do it?</div>
<div><br>
</div>
<div>One easy way to get surgical is to have OpenJDK just stop
worrying about the bad-default-values problem, and let
aftermarket static analyzers like ours take up that mantle.
We can have an annotation to mark classes like Instant, and
we can issue warnings when we see bogus usages (some of
which we warn on anyway). In fact, if you do exactly what
you're planning (so flip back from Instant! to Instant.val,
and give the val type an access modifier), I guess we might
end up doing this in Error Prone anyway, so that people can
make their value types public safely. That would feel
actually totally fine to me. And in the `Instant!` world,
there's not much to hang a modifier on, but we wouldn't care
if we were doing this checking anyway.</div>
<div><br>
</div>
<div>You don't need to explain that "we'd rather release
language features that <i>don't</i> need aftermarket tools
to use safely", I know it. But it is just a platitude
really. I think that any language design expressive enough
to users do good things will inevitably be expressive enough
to let them do bad things too; static analysis always has a
crucial role to play imho. And of course it is always the
trio of language/libraries/tools together that drives the
user's ultimate experience.</div>
<div><br>
</div>
<div>(Now changing back to `String`, a bucket-1 class, I've
been expecting it will be much longer before we'd roll out
!/? to those types, but when we do, I think your particular
question comes out better. "What's the default for `String!`
when we absolutely must have one?" Well, when we must we
must, so we must commit null pollution. We try to issue
enough of the right warnings to live with the fallout. If we
ever make a transition like this, we have to level
expectations; I'm convinced null pollution will be a part of
all of our lives, more so than heap pollution of the
generics kind ever was, but I'm also still optimistic that
it will still be worth it. You could say that today we live
with 100% null pollution...)</div>
<div><br>
</div>
<div><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><font size="4"><font face="monospace">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.</font></font></div>
</blockquote>
<div><br>
</div>
<div>
<div>... which situations already lead to bad behavior /
puzzlers as it is. We might miss a warning we'd rather
have been able to give, but life goes on?</div>
<div><br>
</div>
</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><font size="4"><font face="monospace"> And arrays are
much worse. </font></font></div>
</blockquote>
<div><br>
</div>
<div>Arrays in general, or just the one single
construction path `new TheType![size]` (or `new
TheType.val[size]`)? I would just say please give us new
Arrays methods or syntax that create and fill at once, and
we'll get busy clamping down on everything else.<br>
</div>
<div><br>
</div>
<div><br>
</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>
<div>On 6/15/2022 2:10 PM, Kevin Bourrillion wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">On Wed, Jun 15, 2022 at 10:51 AM Brian
Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank" 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">
<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>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</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>