On Mon, May 9, 2022 at 8:52 AM Brian Goetz <brian.go...@oracle.com> wrote:
We can provide atomicity semantics for sufficiently small objects at no > cost. In practicality this probably means "classes whose layout boils down > to a single 32-bit-or-smaller primitive, or a single reference". > Right, and for long and double we can say they are as atomic as they ever were. > But seriously, we won't get away with pretending there are just 3 buckets > if we do this. Let's be honest and call it B4. > > "Bucket" is a term that makes sense in language design, but need not flow > into the user model. But yes, there really are three things that the user > needs control over: identity, zero-friendliness, atomicity. If you want to > call that four buckets, I won't argue. > I *am* of course only caring about the user model, and that's where I'm saying we would not get away with pretending this isn't a 4th kind of concrete class. > - Classes like LocalDate have no good zero, so the user needs to be able > to disavow the zero value when it doesn't fit the semantics of the class; > > - (the controversial one) Atomicity is simply too confusing and > potentially astonishing to piggyback on "primitive-ness" or > "reference-ness" in a codes-like-a-class world. > (Controversial with me at least; I keep thinking who are these people who can understand the rest of how to safely write non-locking concurrent code yet would struggle with this?) Would I be right that we can achieve primitive unification even without B4? > There is nothing wrong with our delivering many performance gains while > leaving others on the table for later. > > Yes, delivering primitive unification first means you can't have flat > Complex yet. > But they still get *often-flat* Complex? Sounds like *always-flat* Complex is the perfect thing to punt on then. -- Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
