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