Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79534
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain fb.com does not designate 67.231.145.42 as permitted sender)
To: Robert Stoll <php@tutteli.ch>
CC: PHP internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Nullsafe calls
Thread-Index: AQHQFATxvp9RjOsogUO8aMy5/EMi+5yJh4YAgAAo4YA=
Date: Wed, 10 Dec 2014 18:43:16 +0000
Message-ID: <A81E46F6-49DC-47BE-B4D3-2B76C8A387BA@fb.com>
References: <95A581EE-A062-4926-BE44-BCA87FC9B356@fb.com>
 <000b01d01494$bb1c6520$31552f60$@tutteli.ch>
In-Reply-To: <000b01d01494$bb1c6520$31552f60$@tutteli.ch>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <77880336D5D8AB4D94024240DE7E4B10@fb.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Nullsafe calls
From: jwatzman@fb.com (Josh Watzman)

On Dec 10, 2014, at 8:17 AM, Robert Stoll <php@tutteli.ch> wrote:

> First of all, I like the RFC, I think as well that it is a useful feature=
 for PHP and I already have it on my wish list
> ;)
>=20
> Yet, either I misunderstand the section about short circuiting or I propo=
se to change the behaviour.
>=20
> "If $obj is null, when $obj?->foo(..) executes, the arguments will still =
be evaluated."
>=20
> IMO that is wrong. It should not evaluate the arguments since the nullsaf=
e operator (sometimes called "safe navigation"
> operator in other languages - which is the better wording IMO, maybe chan=
ge it? But that is just a detail) is just
> syntactic sugar for making the call only if $bj is not null. So the follo=
wing:
>=20
> [...]
>=20

Take a look at the "short circuit" section where I specifically address thi=
s. It was done to make it easier to reason about in a side-effect-ful langu=
age like PHP. With this behavior, when you see

$x?->f(g(), h())

you don't have to worry about thinking whether g() and h() will actually be=
 evaluated or not -- only the call to f() itself, which is explicitly marke=
d as nullsafe (i.e., might not happen). It also comes down to what you mean=
 by "not making the method call when $x is null" -- we in fact don't make t=
he method call, but we still prepare everything as if we were going to, and=
 just decide not to do it at the last moment.

I feel pretty strongly that this is the correct behavior. It may sound stra=
nge when talking about isolated examples like this, but in the real-world c=
ode I've seen, it is the least confusing. (I'll see if I can dig up a bette=
r example instead of just citing nebulous "real-world code" ;))

Josh