User model stacking

[Brian Goetz]

> Just so we don't lose this history, a reminder that back when we settled on the 3 buckets, we viewed it as a useful simplification from a more general approach with lots of "knobs". Instead of asking developers to think about 3-4 mostly-orthogonal properties and set them all appropriately, we preferred a model in which *objects* and *primitive values* were distinct entities with distinct properties. Atomicity, nullability, etc., weren't extra things to have to reason about independently, they were natural consequences of what it meant to be (or not) a variable that stores objects.

Indeed; it is often a process of "spiraling", where we seem to return to 
places we've already been, but perhaps in a lower energy state.  We came 
by the earlier bucket model honestly, as it approximated the use cases 
we envisioned as most important.   I think its time to rethink the 
three-bucket model, not because three is too big or small a number, but 
because (a) the relationship between the buckets is complex, (b) it puts 
users to some difficult choices between semantics and performance, and 
(c) we have real concerns that hiding the permission to tear behind some 
proxy (e.g., "non null" or "B3") will be too subtle and potentially 
astonishing.

> That was awhile ago, we may have learned some things since then, but I think there's still something to the idea that we can expect everybody to understand the difference between objects and primitives, even if they don't totally understand all the implications. (When they eventually discover some corner of the implications, we hope they'll say, "oh, sure, that makes sense because this is/isn't an object.")

I think this is true for all the aspects _except_ tearing.   I tried the 
argument "it can tear because its not an object" on for size, and I just 
can't imagine people not forgetting it routinely.


> My inclination would probably be to abandon the object/value 
> dichotomy, revert to "everything is an object", perhaps revisit our 
> ideas about conversions/subtyping between ref and val types, and 
> develop a model that allows tearing of some objects. Probably all 
> do-able, but I'm not sure it's a better model. 

I don't think we have to go so far as this.  Just as Valhalla questions 
the previously-universal property of "all objects have identity", we can 
play the same game with "all objects provide integrity guarantees" 
(final field semantics.)  Some classes can shed identity; some further 
can shed the integrity requirements. (Both require a judgement on the 
part of the class author.)  We can then optimize accordingly.

By factoring out atomicity/integrity as an orthogonal semantic 
constraint, we get to a lower energy state for B2 vs B3: "does this 
class have a good zero".  Complex does; LocalDate does not.  And we get 
to a simpler performance consequence of B3.ref vs B3.val: at most an 
extra bit of footprint.  These are both easier to understand.