> On Jun 30, 2021, at 8:39 AM, Brian Goetz <[email protected]> wrote: > > Now, let's talk more about null. Null is a *reference* that refers to no > object. For a flattened/direct object (P.val), null cannot be in the value > set (it's the wrong "kind"), though we can arrange for a primitive to behave > like null in various ways. It's not clear whether this helps or hurts the > mental model, since it is distorting what null is.
This is a good point, if we can hold onto it. Null is a magic one-off boojum that lives in the space of reference types but makes field references and method calls “softly and suddenly vanish away”. Having P.val.default.m() throw an NPE (under default exclusion rules TBD) makes the null boojum arise from a non-reference value, but only just long enough to make the method call go away. (Boo—) Dan’s proposals for default exclusion is loads from uninitialized variables (such as fresh array elements) amount to another boojum-like behavior, of making loads go away (unless the variable has been stored into previously). Again, it’s not directly associated with a reference, but it is null-like, and perhaps NPE is the right way to signal the fault. Of course, our familiar null does not show complete boojum behavior, because you can read, write, and print null without yourself vanishing away. Likewise, even if we do some sort of default exclusion, perhaps we will allow defaults to flow in the same (limited) paths that nulls can flow. And in that case, the #nonewnulls crowd would expect that only the one value null would appear, whenever such a value were converted to a reference. Maybe, in some of these schemes, null is not a primitive, but boojums and boxes are the primitives, and null is a (safely) boxed boojum? — John
