User model stacking: current status

[Brian Goetz]

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.

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!`?

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.

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.)

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.

I swear I didn't think that's where this mail was going to end up.

On 6/15/2022 2:10 PM, Kevin Bourrillion wrote:
> On Wed, Jun 15, 2022 at 10:51 AM Brian Goetz <brian.goetz at oracle.com> 
> wrote:
>
>      - 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."
>
>
> Well, that's what you opted into when you... wait a minute...
>
>     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."
>
>
> Your Kevin's Brain Emulator has gotten pretty decent over time... 
> check whether the next things it said were these (probably so):
>
> 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 
> /being/ a special circumstance; how disproportionate a truth 
> discrepancy we're talking about; etc.
>
> 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 /don't /know it, and therein lies the 
> problem, but do we really have much power to protect such people from 
> themselves?)
>
> 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 /want/ 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.
>
>
> -- 
> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-experts/attachments/20220615/6d56b214/attachment-0001.htm>