Nullsafe

On Tue, 3 Nov 2020 at 16:48, Benjamin Morel benjamin.morel@gmail.com
wrote:

I am wondering why don't we use ordinary -> operator with safe null
handling?

Implicit nullable is terrible, moreover I don't see why users should return
null values more often.
They serve their purpose but most of the time you can use another sane/safe
default of the given
property type.

Moreover, I don't see the issue with another operator as it conveys clear
intent especially in
PHP as everything is null by default (might warn but still).

Technically this isn't a BC break, but it's an enormous change of
semantics for something
which is worse IMHO. Also the operator has already been voted on, accepted,
and implemented.

Regards,

George P. Banyard

However, null value is not a good way to use a default value instead of
an object.
When it comes to polymorphism, we would like to avoid null checks from
being all around.
The same goes not only for ->, but also return / argument type-hintings.

Why do we even need to know that object can be null? Null is just a special
case (there may be other special cases).
Does my customer code need to know about all special cases? Apparently not.
But still, we create another operator to handle this case.
It is ok when it comes to third-party libraries we don't have control over
and sometimes it could return null.

Yet this approach doesn't solve the primary problem. Polymorphism.

You can argue that null can be used to indicate that something was not
found.
But this is not the case for returning null. Here an exception should be
thrown.

When I would like to return some default value of an object, it can't just
be null (because it will pile up the code with ? signs).
I need to create a separate NullObject, which implements a particular
interface used at runtime, and return it's instance.
If an interface declares a returning object, then I have to write even more
boilerplate code for those objects.
It is all for such thing as the default "null" value for an object.

IMHO, simple things should be done in a simple way.
What I currently see is that to do a simple thing, I need to create N
null-classes, whose methods will eventually return "" or 0 or 0.0
or false or [] - generally speaking null.

Le 3 nov. 2020 à 17:38, Eugene Sidelnyk zsidelnik@gmail.com a écrit :

Hello, internals!
I am wondering why don't we use ordinary -> operator with safe null
handling? Programmers will be more prone to return null values. And thus,
in most of cases ?-> will replace ->.
Why do we need another operator, if we can implement null safe in current
operator without BC breaks?

Hi,

In a parallel world where people never commit bugs, yes, this is
reasonable semantics.

However, it happens more than once that a null value occurs by accident
where an object is expected by the programmer. In this case, I very much
prefer to have a Warning or an Error, typically handled by an error handler
which sends a bug report to the developer, then triggers an emergency stop.
That makes it much easier to locate and fix bugs.

Of course, this debuggability facility have to be balanced with the
inconvenience to having to write more code in cases where a null value is
expected. Having to write “?->” instead of “->” in those cases is a minimal
inconvenience. Here, I mean “minimal” in a very literal way: exactly one
character of difference.

Also, there is the following benefit: When I write “->”, I am stating that
the LHS value should never be null; when I write “?->”, I am stating that I
expect that the LHS is sometimes null. Thus, my code is documented in a
very concise way (between zero and one character), which is an aid for any
future reader (including myself).

Aside: The name “nullsafe” is misleading. The operator is not about
safety, it is about handling null values in a concise way. In fact, in some
circumstances, sweeping an unexpected null value under the rug may be
totally unsafe.

—Claude

Hey,

Overall, "null safe" can be very dangerous if made the default.

Here's a scenario where I'd never want "null safe" behaviour (which does
anything but introducing safety):

$accounts->get($receiver)
    ->addFunds(
        $accounts->get($sender)
            ->detractFunds($amount)
    );

In the above scenario, if the first $accounts->get() call returns null
for any reason, you may actually destroy money (funds detracted, but never
added to another account).

The example is simplistic, but it shows that "null safe" is everything but
"safe", and it must instead be used only where it absolutely makes sense to
suppress null reference errors.

Similar behaviour can be observed around cast operators, which are too lax
for most businesses logic:
https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229

Safe = crashes when it should crash.

I agree. The goal here is not to never encounter a crash. The goal is
to make dealing with known potential null values easier. Crashing is
the safer behavior when something happens you might not have taken
into account.

Honestly, in hindsight "nullsafe" might not have been the best term. I
adopted the term from the previous RFC. There are actually quite a few
other languages that use the word "safe" for this feature.

https://en.wikipedia.org/wiki/Safe_navigation_operator

The most obvious alternative would be optional chaining. I'd suggest
renaming it but I don't think that's viable at this point because
those token names might already be used in various tools and
extensions.

Ilija

Hm, yes. If the get() method can return null, then it is a problem.
Currently null is abused to indicate that value was not found.
NotFoundException should be thrown instead.

But.. yeah, we can't just use nullsafe by default because of abuse of
null.

Heya,

Hello, internals!
I am wondering why don't we use ordinary -> operator with safe null
handling? Programmers will be more prone to return null values. And thus,
in most of cases ?-> will replace ->.
Why do we need another operator, if we can implement null safe in current
operator without BC breaks?

Overall, "null safe" can be very dangerous if made the default.

Here's a scenario where I'd never want "null safe" behaviour (which does
anything but introducing safety):

$accounts->get($receiver)
    ->addFunds(
        $accounts->get($sender)
            ->detractFunds($amount)
    );

In the above scenario, if the first $accounts->get() call returns null
for any reason, you may actually destroy money (funds detracted, but never
added to another account).

The example is simplistic, but it shows that "null safe" is everything but
"safe", and it must instead be used only where it absolutely makes sense to
suppress null reference errors.

Similar behaviour can be observed around cast operators, which are too lax
for most businesses logic:
https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229

Safe = crashes when it should crash.

But wait!

In your example, funds won't get detracted. If $accounts->get($receiver)
will return null, then everything inside addFunds(...) will not be
executed.
Your example (simplified): https://3v4l.org/38Dk3

Another one:

function expensive_function() {
    var_dump(__FUNCTION__);
}

$foo = null;

$foo?->baz(expensive_function());

Heya,

Hello, internals!
I am wondering why don't we use ordinary -> operator with safe null
handling? Programmers will be more prone to return null values. And thus,
in most of cases ?-> will replace ->.
Why do we need another operator, if we can implement null safe in current
operator without BC breaks?

Overall, "null safe" can be very dangerous if made the default.

Here's a scenario where I'd never want "null safe" behaviour (which does
anything but introducing safety):

$accounts->get($receiver)
    ->addFunds(
        $accounts->get($sender)
            ->detractFunds($amount)
    );

In the above scenario, if the first $accounts->get() call returns null
for any reason, you may actually destroy money (funds detracted, but never
added to another account).

The example is simplistic, but it shows that "null safe" is everything but
"safe", and it must instead be used only where it absolutely makes sense to
suppress null reference errors.

Similar behaviour can be observed around cast operators, which are too lax
for most businesses logic:
https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229

Safe = crashes when it should crash.