Feedback on Null-Restricted and Nullable Types

[Brian Goetz]

The following was received on valhalla-spec-comments.  

Point #1 rests on an assumption that the goal of this feature is to eliminate, or at least strongly discourage, nulls.  This is a common assumption — many people are so-called “null haters” — but encouraging or rewarding such biases is not the role of the langauge.  Nulls are not intrinsically bad; the problem with nulls is that they are so often unexpected, and so people code as if they would never happen.  Reflecting nullity in the type system allows you to reason about when they are expected, and make reasoned choices about where nulls are appropriate or not.  

You state your position pretty explicitly here:

>> The syntax to use null must be "disgusting enough" in order to
>> discourage people from using it.

I’m not going to criticize your opinions about nulls, but it is also OK to have different opinions about nulls, and it’s not the role of the language to insist that one or the other is the only valid set of feelings about it.  

Your second point is what we call “inventing a new null”; it is a tempting answer, but is overwhelmingly likely to just make the problem worse, because now there are two ill-behaved states.  


> On Sep 10, 2024, at 10:46 AM, Enrique <enrique.arizonbenito at gmail.com> wrote:
> 
> REF: https://openjdk.org/jeps/8303099
> 
> Feedback 1:
> 
> Using the syntax "Foo?" for nullables values does not discourage the
> use of nulls in code.
> 
> In my experience working with Kotlin, novice (and not so novice)
> developers just find themselves comfortable enough adding an extra
> character and continue to infest code with nulls.
> 
> The syntax to use null must be "disgusting enough" in order to
> discourage people from using it.
> 
> For example something like Foo!!!NullBackwardCompliant!!!. This syntax
> is ugly enough to scare people about using it.
> 
> 
> Feedback 2:
> Most people naively tends to use null in next scenarios:
> 
> * A class/record must be initialized, but due to the data flow, some
> of its members are not yet known in "present time". They depend on
> future input data/processing.
> * Some member must not take any value in a given context.
> 
> Ideally the JVM would be extended to support "FUTURE" and "NA" (Not
> Apply) values in parallel to null. Any read must throw a
> FuturePointerException or NAPointerException.
> While the behaviour looks similar to the current null and
> NullPointerException, it makes error debugging much easier to
> understand:
> * A FuturePointerException promptly warns about some race condition:
> Some code tried to read a value before some process (maybe another
> thread) initialized it.
> * A NAPointerException promptly warns about some error in the business
> logic. Some code didn't contemplate the NA scenario.
> 
> "catch" blocks will also be able to make much more sensible decisions
> (when compared to the pervert NullPointerException).
> 
> Without any JVM extension, a compiler most probably can automate a
> similar behavior with a syntax similar to:
> 
> var Foo1 = Future
> var Foo2 = NA
> 
> Foo1 and Foo2 are **NOT** nullables.
> 
>  Foo2 becomes a constant (It will never change once defined and the
> compiler can make many verifications out of the box).
> 
>  Foo1 must never be read until a given value is provided (after which
> it will probably become constant).
> 
> 
> My two cents!
> 
> Enrique Arizón Benito
> Software Gardener