On Mon, Apr 25, 2022 at 1:19 PM Brian Goetz <brian.go...@oracle.com> wrote: > > My understanding was we were going to guide most users towards B2 > values and would treat B3 as the rare, "expert" mode, for when density > really matters. Does that decrease the education problem? > > > I am not convinced it does, but am open minded to see if there are other > things we can do at the declaration site to mitigate. (I also know that this > topic is one where we’ve tried to convince ourselves of a lot of things, and > in the cold light of morning, had regrets.) The problem is that from the > client perspective, Complex is just another class in a library; if there’s > anything they have to think about before using it in its most elemental form, > they should have a chance to do so. > Users who have already opted into using a B3 will be annoyed that they have to use the bad name to get what they already said they wanted. I don't think our intuition on Integer vs int helps us here as we're too used to speaking different names when we want one or the other. Author intent - in this case choosing the right default - should be respected. Users who want the default for B3 to be a reference should probably have picked a B2 already.
> > ".prim" anyone? (backs slowly away from the bikeshed) > > > “Not terrible" > > > 3. This change would permit compatible migration of an id-less to primitive > class. It's a no-op, and use sites are free to migrate to the value type if > and when ready. And if they already expose the type in their API, they are > free to weigh the costs/benefits of foisting an incompatible change onto > *their* users. They have facilities like method deprecation to do it with. In > the current plan, this all seems impossible; you would have to fix all your > problematic call sites *atomically* with migrating the class. > > > This is one of my favorite aspects of this direction. If you recall, you > were skeptical from the outset about migrating classes in place at all; the > previous stake in the ground said “well, they can migrate to value classes, > but will never be able to shed their null footprint or get ultimate > flattening.” With this, we can migrate easily from VBC to B2 with no change > in client code, and then _further_ have a crack at migrating to full flatness > inside the implementation capsule. That’s sweet. > > > Changing from a B2 -> B3 changes the default spelling from "L" -> "Q". > Why does this have to be done atomically? Existing descriptors - > spelled with "L" - would still work. Code that's recompiled would > pick up the Q descriptors. If the author wants Qs, and gets them > either "for free" or by adding ".val", there's the same compatibility > concerns.... they have to take explicit action to get what they want > and to keep descriptors working. > > > What I’m thinking here about migration is that existing APIs can say > “Optional” but field declarations can say Optional.val, getting additional > footprint / flattening benefits, without perturbing the APIs (and with cheap > conversions.) Aren't most of the migration cases (at least for existing VBC) targeting B2? They need to keep the reference semantics due to existing code using null and will still get optimized inside a compiled body. I'm a little concerned we're starting to undo the separation between B2 & B3 (just add .val to any B2 class) and will drag ourselves back into the quagmire. B2 and B3 are different points on the spectrum and we should respect the user's intention when they pick one of those points. If a user has picked B2, then they are opting out of worrying about tearing and don't expect impossible values to be generated out of races. B3 users are aiming for optimal memory density (flattening) and accept the risks of tearing. Migration compatibility shouldn't take precedence by claiming the "good" name. > 6. It's very nice when the *new syntax* corresponds directly to the *new > thing*. That is, until a casual developer *sees* `.val` for the first time, > they won't have to worry about it. > > > That's nice initially but a few releases after B3 values are available > will we still want the syntax to highlight (scream?) "new thing”? > > > Yes, that’s the risk. (Still, primitives today LOOK DIFFERENT from class > names.) So we should guide primitive B3 classes to use lower case names? "complex" rather than "Complex"? This started tongue in cheek but it's kind of growing on me as a convention. It matches the existing primitives, makes it clear at glance (no need to carry a type dictionary in your head), and works fine with the ".ref" escape hatch. --Dan
