Non-Nullable type syntax

[Remi Forax]

----- 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