Nullability syntax

[Archie Cobbs]

My opinion only of course, but I think this would be a step backwards.

You would be adding an extra level of mental redirection that a developer
would have to go through every time they see "String".

Now sometimes the cost of a level of indirection is worthwhile .. for
example, using "import java.util.List" means in exchange for that extra
level of redirection, we can say "List" instead of "java.util.List". So
import statements are a worthwhile trade-off. Helping the cause, it's rare
that I would ever declare a class named "List" in the unnamed package, and
I haven't used AWT in 20 years, so these days when I see "List" there's not
much ambiguity.

But "String" is used everywhere. And yet we are only talking about saving a
single character (what I love about the nullity syntax idea is that in a
single character, so much information that I need constantly, all over the
place, is being conveyed). So the trade-off doesn't seem worth it.

There’s clarity in only being allowed to use 1 type of punctuation in a
> class.


Hmm, I actually feel the opposite. Most code is write once, read many, so
you want to optimize for the reading of it, not the writing of it.

-Archie

On Thu, Apr 10, 2025 at 8:54 AM Jonathan F <livedinsquares at gmail.com> wrote:

> It seems the syntax of nullable types is extra-important for its
> usability, so here’s an idea which perhaps the EG hasn’t considered. Remi
> has mentioned a 2-states model? - maybe this is different:
>
> - Assume there’s some way (any way) to specify default nullability within
> some scope: to set either that String means String!, or that it means
> String?. If you don’t specify anything, as now, String means unspecified
> null.
>
> - Then: if you set default nullability to ! , you’re allowed to write
> String or String? but not String! (i.e. you can’t belabour the
> non-nullability of a particular String)
>
> - Likewise if you set default nullability to ? , you’re allowed to write
> String or String! but not String?. Or maybe we don’t even need this default.
>
> - (I think…) if you don’t set a default so it's 'unspecified null’ (as
> now), then neither String? nor String! is allowed: they force you to set a
> default.
>
>
> The point of this is:
>
> - There’s clarity in only being allowed to use 1 type of punctuation in a
> class. And seeing it tells you there’s a default.
>
> - If you see ? or ! in a sample of code you’ll know what a bare String
> means: ’the opposite'.
>
> - Pasting raw code between two classes with different nullability will
> often give compile errors from mixed punctuation (unless your IDE adjusts
> the code, which hopefully IDEs will).
>
> - This fits with simple ways to convert an existing class to being
> null-aware: set the default to !, so existing types are reinterpreted as
> null-restricted, then fix errors by adding ? piecemeal. But if you want to
> make minimal changes you may want to set the default to ? instead, then add
> ! piecemeal; or again maybe we don’t need that default - even simpler.
>
> As for actually using ‘unspecified null’ (which I hope will be rare in
> null-aware code) - maybe String* or even String!? is OK.
>
> I hope that (or something like it) makes sense.
>
> Jonathan
>
> Jonathan Finn
>
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250410/223c6889/attachment-0001.htm>