Nullability in Java
Clement Cherlin
ccherlin at gmail.com
Fri Oct 11 16:46:01 UTC 2024
Hello,
I did some more thinking and have clarified my responses.
On Wed, Oct 2, 2024 at 9:30 AM <forax at univ-mlv.fr> wrote:
> 1) If you have a code like:
> String s = f();
> g(s);
If 's' has its null-marker computed automatically, the null marker will
> flow naturally without the user having to update his code each time the
> API of a dependency is updated to use null-marker.
I don't follow. If I null-marked my code consistently, why would I need to
update it when my API dependencies change? On the other hand, if I marked
my code inconsistently with my API dependencies, then I probably need to
update my code, because my assumptions were incorrect!
2) until now, the type of a local variable would never change, we have even
> introduced the concept of binding to explicitly avoid a local variable to
> have its type changed.
> But we also want the nullability part of the type of a local to change
> dependending on the control flow, so having a way to denote the nullability
> on a local's type given that it can changed is weird.
To put my earlier comments much more succinctly, "nullability" is not the
same as "nullness". The nullability of a variable's type is always how it
is null-marked. Nullability does not change, regardless of control flow.
Nullness does change with control flow. Values of nullable types have
different nullness at different points in a program.
Declaring static nullability enhances dynamic nullness analysis and
helps detect bugs.
For that reason, we should allow and encourage null-marking local
variables.
Cheers,
Clement Cherlin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20241011/b7133e40/attachment.htm>
More information about the valhalla-spec-observers
mailing list