[RFC] Nullsafe operator

It introduces the nullsafe operator ?-> that skips null values when
calling functions and fetching properties. In contrast to the last few
attempts this RFC includes full short circuiting.

I like it a lot! Concise and clear RFC.

From having used a similar feature in TypeScript I can say it is quite
convenient, easy to get used to and makes for much leaner code.

IMO not having it on array accesses isn't so bad as with arrays you can
easily isset($deep['into']['the']['array']) in one go, while with
objects and getters etc it tends to lead to much uglier and repetitive
code like:

    if ($foo && $foo->getBar() && $foo->getBar()->getBaz()) { ... }

So yeah, +1

Best,
Jordi

--
Jordi Boggiano
@seldaek - https://seld.be

Hi internals

I'd like to introduce another RFC I've been working on:
https://wiki.php.net/rfc/nullsafe_operator

It introduces the nullsafe operator ?-> that skips null values when
calling functions and fetching properties. In contrast to the last few
attempts this RFC includes full short circuiting.

Let me know what you think.

The semantics look reasonable to me, but I'd recommend including some
discussion on the rationale behind the short-circuiting behavior in the
RFC. That is, what the options are, and why this is the best option (which
is not the option that the previous RFC on this topic picked). It would
also be nice to cross-reference semantics of ?-> in other languages that
have it, to make sure we don't introduce any unexpected WTFs for people
switching between languages. I think the specified behavior is consistent
with what everyone else does, but I haven't checked to be sure.

Regards,
Nikita

Hi internals

I'd like to introduce another RFC I've been working on:
https://wiki.php.net/rfc/nullsafe_operator

It introduces the nullsafe operator ?-> that skips null values when
calling functions and fetching properties. In contrast to the last few
attempts this RFC includes full short circuiting.

Let me know what you think.

Ilija

Hi Internals,

Wouldn't it make more sense to make isset smarter? So that it can
handle these situations just like it would with array access. That
way you could use the null coalescing operator as well.

I don't see many situations where you would be selective in which
method in the chain you would want to make nullsafe and which ones you
wouldn't. I think it would mostly be the entire chain, in which case
using ?? would be much less verbose. In the few cases where you
want to be specific in which are nullsafe and which ones aren't you
can introduce one more variable.

Using the first example in the RFC this would visully be far nicer and
more readable about the intent:

$country = $session->user->getAddress()->country ?? null;

Besides, shouldn't the example really be:

$user->getAddressCountry();

I don't recall ever having to nest three levels like that example. I
know the example is contrived, but wouldn't you know if you have a
logged in user or not? Then just have a simple getter on the user for
what you need to check. Chances are those variables you're trying to
save will be used elsewhere, or if not, refactor.

Also, assuming we have control over the User class, you can either
make address a property or use the magic getters (that many frameworks
have, love or hate them). Even the new new accepted Constructor
Property Promotion would be helpful in facilitating that. Basically
we can easily get around this problem already, and some frameworks do
it by default. If not, writing one getter where you have to check a
few things is IMO far nicer than a long chain of possibly null
objects.

This is how I would solve the issue, assuming we're just in the
controller we don't make anything specifically for the User or Address
classes and no other uses for those specifically are needed.

protected function getCountry()
{
    $user = $this->session->user ?? null;
    if ($user === null)
        $this->redirectToLogin();

    if ($user->getAddress() === null)
        return null;

    return $user->getAddress()->country ?? null;
}

Chaining that many objects together that may or may not be null just
seems so wrong to me.

My concern is that we would start seeing ?-> far too often and it
would promote some lazy habits, because people would add it "just in
case". Personally I think it should be more explicit when we are
null-checking, and since the -> object access usually doesn't have
spaces around it, it could "muddy the water".

It reminds me too much of the proposed "unary null coalescing
operator", which also reminds me of the error control operator. Maybe
make the syntax ->@ to be more clear?

Sorry if I come off a bit harsh, but I don't see the need for this as
other solutions to this problem are more favourable IMHO. As much as
it can be annoying sometimes, the Call to a member function foo() on null is a very useful error.

Thanks,
Peter

BIG THUMBS UP for this feature.
As was mentioned that TypeScript uses this and saves developers lots of
time by avoiding nested null checking.
I suggest in the RFC including a list of other languages that have this
feature.

Hi internals

I'd like to introduce another RFC I've been working on:
https://wiki.php.net/rfc/nullsafe_operator

It introduces the nullsafe operator ?-> that skips null values when
calling functions and fetching properties. In contrast to the last few
attempts this RFC includes full short circuiting.

Let me know what you think.

Ilija

Hi internals

I'd like to introduce another RFC I've been working on:
https://wiki.php.net/rfc/nullsafe_operator

I've reworded some things and added more information on short
circuiting. Functionality wise the RFC has remained the same.

Since there was little negative feedback I'd like to put this feature
to a vote in ~1 week. If you have any concerns or criticism please let
me know in time.

Ilija

Hi Ilija,

I'd like to introduce another RFC I've been working on:
https://wiki.php.net/rfc/nullsafe_operator

It introduces the nullsafe operator ?-> that skips null values when
calling functions and fetching properties. In contrast to the last few
attempts this RFC includes full short circuiting.

Would this still work together with short-circuiting and the null
coalesce operator?

I just didn't see a clear example about this but also figured that could
be a practical way to use this:

$country = $session?->user?->getAddress()?->country ?? 'defaultCountry';

(hope the example is readable, my MUA insists on wrapping the lines)

thanks,

• Markus