<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">FTR, I’m really happy with the user model as of this point.</p>
<p dir="auto">The things I like best about it are:</p>
<ul>
<li>just the right spacing between the two types and their class (no extra classfiles, in particular)</li>
<li>safety by default everywhere</li>
<li>high speed numerics are supported as a non-default less-safe decision</li>
<li>no more discussion of non-atomic refs (that always gave me the willies)</li>
<li>uniform meaning of <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C</code> (a safely published ref-type)</li>
<li><code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">Object::getClass</code> returns a predictable ref-mirror (I always wanted that)</li>
<li>encapsulation authors have authority over uses of the new features</li>
<li>the new levers “feel like” existing encapsulation decisions</li>
<li>no more broad appeals like “now, everybody, just remember that B3s are <em>never atomic</em>”</li>
<li>no need yet for new features like <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">require x</code></li>
<li>good correspondence with our existing JVM prototype (<code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.val</code> ⇒ <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">QC;</code>)</li>
</ul>
<p dir="auto">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.</p>
<ol>
<li>identity = B1</li>
<li>better VBC (by-default private companion, by-default atomic) = B2</li>
<li>full-flat primitive (explicitly public non-atomic companion) = B3n</li>
<li>atomic primitive (explicitly public companion, but no tearing) = B3a</li>
<li>internally-flat VBC (private companion, tricky full-flat private vals)</li>
</ol>
<p dir="auto">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”.)</p>
<p dir="auto">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.</p>
<p dir="auto">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.</p>
<p dir="auto">— John</p>
<p dir="auto">On 13 Jun 2022, at 16:04, Brian Goetz wrote:</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">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.</p>
<p dir="auto">"value class X" means:</p>
<p dir="auto"> - Instances are identity-free<br>
- There are two types, X.ref (reference, nullable) and X.val (direct, non-nullable)<br>
- Reference types are atomic, as always<br>
- X is an alias for X.ref<br>
…</p>
</blockquote>
</div></div></body>
</html>