Non-Nullable type syntax
Remi Forax
forax at univ-mlv.fr
Mon Aug 17 22:27:36 UTC 2020
----- Mail original -----
> De: "Kevin Bourrillion" <kevinb at google.com>
> À: "Kye" <yeung.kye at pm.me>
> Cc: "amber-dev" <amber-dev at openjdk.java.net>
> Envoyé: Lundi 17 Août 2020 20:37:22
> Objet: Re: Non-Nullable type syntax
> 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.
yes, it's like you have raw type for generics, you need something that represents the previous semantics, when the nullability information is unknown.
>
> 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.
for 2, i'm using a per package annotation and it's not that bad.
>
> 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.
Kotlin as the same issues and it works in practice, so there is hope,
like with generics migration, it will take times, but i remember a lot of people predicting that generics will be a failure because nobody will use them.
The real question for me is more, does the whole Java community wants nullability backed into the language above everything else ?
Before the introduction of generics, there were a lot of blogs saying that Java sucks because it doesn't have generics (GoLang is actually in the same situation),
I don't see a lot of people arguing that Java is dead because it doesn't have nullability backed into the language, but maybe i'm wrong ?
Rémi
>
>
> 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
More information about the amber-dev
mailing list