Nullity (was: User model stacking: current status)

[Brian Goetz]

> On Thu, May 12, 2022 at 5:22 AM Brian Goetz <brian.goetz at oracle.com> 
> wrote:
>
>      - there is a nullability-injecting conversion from T! to T? (this
>     is a widening conversion)
>
>
> I think we'd expect full subtyping here, right? It needs to work for 
> covariant arrays, covariant returns, type argument bounds, etc.

There's two questions here, one at the language level and one at the VM 
level.

At the VM level, `I` is not going to be a subtype of `LInteger`.  At the 
language level, we have a choice of whether to use subtyping or widening 
conversions, but given that the VM is expecting a widening conversion, 
it is probably better to align to that.  (Similarly, the distinction 
between int and Integer in overload selection is based on the assumption 
that they are not subtypes, but instead related by conversions.)

So while abstractly, the value sets may form subsets, which says that at 
least _structurally_ they are subtypes, we try to avoid having subtype 
relationships between things that use different representations, because 
it creates difficult seams in translation, and lean on conversion 
machinery instead.

In practice, the distinction between "int widens to long" and "int <: 
long" is not particularly visible, except in corner cases like "boxing 
is allowed in loose invocation contexts but not strict invocation 
contexts."

>
>     and then we get to decide: which conversions are allowed in
>     assignment context?  Clearly a nullability-injecting conversion is
>     OK here (assigning String! to String? is clearly OK, it's a
>     widening), so the question is: how do you go from `T?` to `T!` ? 
>     Options include:
>
>      - it's like unboxing, let the assignment through, perhaps with a
>     warning, and NPE if it fails
>      - require a narrowing cast
>
>
> Yes, I do think we want a cast there (a special operator for it is 
> very helpful so you don't have to repeat the base type), but as far as 
> I know the case could be made either way for error vs. warning if the 
> cast isn't there.

This is the decision point I want to highlight; while one might at first 
assume "well obviously you should explicitly convert", there are 
actually more choices than the obvious one, and it is a decision that 
should be made deliberately.

> But, suppose the *class* is identifiable in some way as friendly to 
> that default value. I'm still struggling to think through whether we 
> also strictly need to have something at the use site equivalent to 
> `.val`. Or if just knowing the nullness bit is enough. It may be 
> fundamentally the same question you're asking; I'm not sure.

I think we may be saying the same thing.  It is a declaration-site 
property as to whether we want to tolerate uninitialized values.  We do 
for int; we probably also do for Complex, not only because "its a number 
and the existing numbers work that way", but because there's a 
performance tradeoff, which is that being intolerant of uninitialized 
values has a footprint cost, and effectively doubling the size of a flat 
`Complex[]` will not be appreciated.

For such a zero-tolerant class, there is still room to make the choice 
at the use site which flavor you want.  One positive consequence of 
having decomplected atomicity from { nullity, primitive-ness } is that 
it becomes *possible* to spell this distinction with emotional sigils, 
rather than some weirder thing (e.g., .val.)

>
>     What this short discussion has revealed is that there really are
>     two interpretations of non-null here:
>
>      - In the traditional cardinality-based interpretation, T! means:
>     "a reference, but it definitely holds an instance of T, so you
>     better have initialized it properly"
>      - In the B3 interpretation, it means: "the zero (uninitialized,
>     not-run-through-the-ctor) value is a valid value, so you don't
>     need to have initialized it."
>
>
> I'm not sure these are that different. I think that as types they are 
> the same. It's the conjuring of default values, specifically, that 
> differs: we can do it for B2, B3, and B3!, and we don't know how to 
> find one for B2!. But that's not a complication, it's just precisely 
> what we're saying B2 exists for: to stop that from happening.
>

This question is at the heart of this sub-thread.

I think what you are saying is that for ref-only classes (B1 and B2), 
then T! is a _restriction_ type (which we will probably erase to the 
erasure of T), whereas for for zero-capable classes (B3), then `T!` is a 
true projection which makes the null value *unrepresentable*, and that 
you're OK with that.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20220512/58ff6693/attachment.htm>