User model stacking: current status

[Dan Smith]

> On May 6, 2022, at 8:04 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> Thinking more about Dan's concerns here ...
> 
> On 5/5/2022 6:00 PM, Dan Smith wrote:
>> This is significant because the primary reason to declare a B2 rather than a B3 is to guarantee that the all-zeros value cannot be created. 
> 
> This is a little bit of a circular argument; it takes a property that an atomic B2 has, but a non-atomic B2 lacks, and declares that to be "the whole point" of B2.  It may be that exposure of the zero is so bad we may eventually want to back away from the idea, but let's come up with a fair picture of what a non-atomic B2 means, and ask if that's sufficiently useful.

Fair. My interpretation is that we decided to create B2 because we weren't satisfied with the lack of guarantees offered to no-good-default classes that were reference-default B3s. So in that historical sense, B2s exist to offer guarantees.

>> This leads me to conclude that if you're declaring a non-atomic B2, you might as well just declare a non-atomic B3. 
> 
> Fair point, but let's pull on this string for a moment.  Suppose I want a null-default, flattenable value, and I'm willing to take the tearing to get there.  So you're saying "then declare a B3 and use B3.ref".  But B3.ref was supposed to have the same semantics as an equivalent B2!  (I realize I'm doing the same thing I just accused you of above -- taking an old invariant and positiioning it as "the point".  Stay tuned.)  Which means either that we lose flattening, again, or we create yet another asymmetry between B3.ref and B2. Maybe you're saying that the combination of nullable and full-flat is just too much to ask, but I am not sure it is; in any case, let's convince ourselves of this before we rule it out.

Yeah, I think my mindset has been here—non-atomic flat nulls are just more trouble than they're worth—but I'm open to discovering a compelling use case.