There are five buckets now

[John Rose]

FTR, I’m really happy with the user model as of this point.

The things I like best about it are:
  - just the right spacing between the two types and their class (no 
extra classfiles, in particular)
  - safety by default everywhere
  - high speed numerics are supported as a non-default less-safe 
decision
  - no more discussion of non-atomic refs (that always gave me the 
willies)
  - uniform meaning of `C` (a safely published ref-type)
  - `Object::getClass` returns a predictable ref-mirror (I always wanted 
that)
  - encapsulation authors have authority over uses of the new features
  - the new levers “feel like” existing encapsulation decisions
  - no more broad appeals like “now, everybody, just remember that B3s 
are *never atomic*”
  - no need yet for new features like `require x`
  - good correspondence with our existing JVM prototype (`C.val` ⇒ 
`QC;`)

The surprising outcome of this is we now have (by my count) five 
buckets.  And I don’t think we mind, because they are all about 
encapsulation choices.

1. identity = B1
2. better VBC (by-default private companion, by-default atomic) = B2
3. full-flat primitive (explicitly public non-atomic companion) = B3n
4. atomic primitive (explicitly public companion, but no tearing) = B3a
5. internally-flat VBC (private companion, tricky full-flat private 
vals)

Yeah, the eagle-eyed designer might try to toss the last guy or two off 
the island.  But to what purpose?  The encapsulation paradigm means we 
trust the author of the class to set things up.  Class authors like that 
sort of trust, as long as we don’t undermine their decisions with 
use-site overrides.  (Which, in the Java world, we call “security 
bugs”.)

One thing I’m a little sad to give up on is the word “primitive” 
for any of these types.  It felt nice to try on the idea of 
user-definable primitives.  As you can see from my list above, they do 
survive in some form.  But not as a primary, bright-line distinction in 
the language, other than the existing legacy distinction.  I think 
that’s fine.  We always knew we were doubling down on class-like 
declarations, so it feels really good to be using them fully, including 
the encapsulation features.

Another result of backing away from “primitive” is that we have to 
engage with the question of “where are the objects?”  Obviously 
every non-null value of a variable whose type is an identity class 
refers to “an object”.  But beyond that it gets dicey and we will 
have to adjust our agreements, I think.  This is probably worth a 
separate thread, which I will start, and which I expect Kevin will be 
very interested in.

— John

On 13 Jun 2022, at 16:04, Brian Goetz wrote:

> I've done a little more shaking of this tree.  It involves keeping 
> the notion that the non-identity buckets differ only in the treatment 
> of their val projection, but makes a further normalization that 
> enables the buckets to mostly collapse away.
>
> "value class X" means:
>
>  - Instances are identity-free
>  - There are two types, X.ref (reference, nullable) and X.val 
> (direct, non-nullable)
>  - Reference types are atomic, as always
>  - X is an alias for X.ref
> …
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-experts/attachments/20220713/1faab50e/attachment-0001.htm>