[aindhaden]

Unfortunately they decided to go with explicit nullables instead of implicit, which means that you still have to go and write/modify all your code explicitly to benefit from this. Which pretty much negates the benefit.

Implicit nullables across the board are extremely useful when designing loose-coupled and natively unit-testable code. They allow you to design code paths with a minimum of fuss (don't worry about a parameter if you're not actually using it right now), they allow you to substitue simple nulls instead of mocks, and can help to deep-map code paths and use cases for specific parameters.

Another issue is the inconsistent manner of dealing with errors generated when attempting to use a parameter as its actual non-null type. They range from notices to fatal errors (non-catchable with try). By contrast, in Java you consistently get a "null pointer exception" when this happens (and Java also has implicit nullables).

[dom0]

Implicit nulls are the so-called "billion dollar" mistake in Java that has been worked around and tried to be fixed in almost every other JVM language. That the PHP folks did not repeat the same mistake might suggest that they, after all, are not the worst language designers (anymore?).

[aindhaden]

I suspect we may be talking about two different approaches. Nobody _wants_ to trip on a null reference, naturally. But there are different ways of achieving that, and some of them yield additional benefits.

One way is to forbid them outright (which is what Tony Hoare regretted not doing when he made the "billion dollar mistake" presentation IIRC).

Allowing them to run unchecked is obviously not a good idea.

The "null object pattern" is another option, where the nulled var will be replaced on the fly with a "mock" that will not cause any trouble.

Here's another approach. It's more convoluted and you need the language to help you with it (Java does), but it return it offers the benefits described in my previous post:

* Implicit nulls across the board. * No penalty if the nulled variable is not used in an ambiguous manner (passing-on and checking the reference are ok). * Consistent runtime fail-fast behavior if the nulled variable is used in a manner that requires the declared type. (Java throws an exception, which uncaught leads to the stop of the program, thus preventing undefined behavior, but also allows the programmer to catch and recover.) * Most importantly: you DO NOT check for nulls with inline checks or assertions, but instead rely on unit tests to validate intended behavior.

The technique is called "passing nulls" in UT.

The end result is a more "relaxed" code, which promotes loose coupling and leads to more flexible code paths, which in turn make possible additional patterns. If you're not hurting anything by nulls why be forced to conform to rigid declarations? And if you are hurting something, then you will be forced to deal with it in a consistent manner.

[dom0]

> Here's another approach. [...]

How is that different from the usual approach in Java, which exactly produces the problems observed?

Other languages, eg. Kotlin and now PHP enforce that variables and parameters that are declared to be not null are not null. Not null is the default behaviour. If you want nullable vars or params, then you have to declare it through `?`.