Non-Nullable type syntax

[Kevin Bourrillion]

Just to clarify, the current meaning of an unadorned reference type is not
actually "nullable". It's "intended nullability unknown".

Take the example of a method return type. Today, as far as the language is
concerned, its nullability is unknown, so if a tool wants to be *strict* (no
false negatives but many false positives) it has to treat it as nullable,
as you say. But if it is trying to be *lenient* (no false positives but
many false negatives), then it's the opposite, it has to treat it as
non-nullable. And neither a strict nor a lenient approach can be said to be
the correct one in general.

Notably though, if you take the example of a *parameter* type instead, the
situation just described is reversed. So that's why this really is a
distinct third state.

Or instead of all the above, I could have just said: Kotlin does this
correctly.

If these adornments were ever to come to Java, I think there are really
only two ways it could go:

1. You need to mark every non-nullable type with the bang and every
nullable type with the question mark, and in well-curated code eventually
every reference type would have one or the other. Yuck.
2. Or there is a way to mark an entire scope as being "non-nullable by
default" somehow, so that only nullable types need to be called out. This
is also yuck in different ways.

Either would be extremely tough to pull off. It would be essential to first
have an actually standardized annotation-based solution, which is something
I and a few others are slowly working toward
<https://drive.google.com/file/d/15wZ-cVPkfsNYzSez9WrAF4gEjWNzlDAD/view>
(slides
are a bit outdated in a few ways). Having very high JDK library coverage
(applying our annotations by way of separate annotation-overlay files)
would be required before transitioning to a language feature. But still,
this may be prohibitively difficult and it's probably likely we never get
there.


On Mon, Aug 17, 2020 at 11:00 AM Kye <yeung.kye at pm.me> wrote:

> Hi,
>
> This might be a ridiculous suggestion but why don't Java add a bang in the
> type declaration to indicate non-nullable and leave the current meaning
> nullable.
>
> Like GraphQL schemas, and opposite to the Kotlin question mark.
>
> Obviously this wouldn't break anything existing and would allow for the
> same benefits the aforementioned languages have. Then everything could
> unify to this language construct, no need for the not universally used
> @Nullable nor Optional.
>
> Kind regards,
>
> Kye
>
> Sent from ProtonMail mobile



-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com