Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79518
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: Andrea Faulds <ajf@ajf.me>
CC: PHP internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Nullsafe calls
Thread-Index: AQHQFATxvp9RjOsogUO8aMy5/EMi+5yIauGAgAADuYA=
Date: Tue, 9 Dec 2014 23:31:30 +0000
Message-ID: <F15686D7-D103-4EAF-9678-5623BD0C33E8@fb.com>
References: <95A581EE-A062-4926-BE44-BCA87FC9B356@fb.com>
 <0A19AD11-E5B4-4C4E-A69A-C7D6F2E2244A@ajf.me>
In-Reply-To: <0A19AD11-E5B4-4C4E-A69A-C7D6F2E2244A@ajf.me>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <ABC3CFB7DA9E6D4EBD11A12EBECB82B6@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 9, 2014, at 3:18 PM, Andrea Faulds <ajf@ajf.me> wrote:

>> On 9 Dec 2014, at 23:07, Josh Watzman <jwatzman@fb.com> wrote:
>>=20
>> Hey internals! A useful feature that Hack picked up in the last few mont=
hs are "nullsafe calls", a way of propagating failure forward in a series o=
f chained method calls to the end of the whole computation, getting rid of =
a lot of the boilerplate in the middle. I think the feature would be a good=
 one for PHP as well, so I'm submitting this RFC to add it -- you can see t=
he RFC itself for a full discussion of the motivation for the feature, as w=
ell as the feature itself:
>>=20
>> https://urldefense.proofpoint.com/v1/url?u=3Dhttps://wiki.php.net/rfc/nu=
llsafe_calls&k=3DZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=3DNOz6YOAf%2F6vcJtVVDrd%=
2F2w%3D%3D%0A&m=3DPWfP%2BxZeAyjdTrP6VD3DSUmxrBjiUYvk0TNF5G5e6Ag%3D%0A&s=3D1=
6ce2443111cdb22b84068fd36e93c14d68190e3fe9a2302cf576464b71d28bd
>=20
> Hi!
>=20
> In a way, this would complement the ?? null coalescing operator we=92re a=
dding. :)
>=20
> Two thoughts, though:
>=20
> 1) Wouldn=92t it be useful to also have this for properties? If you=92re =
going down a long list of property accesses, $foo?->bar?->qux is probably n=
icer than if ($foo !=3D=3D NULL && $foo->bar !=3D=3D NULL) { $foo->bar->qux=
; =85 } - on the other hand, the ?? operator partly covers this and even ha=
ndles arrays, as you can do $foo->bar[=91elePHPant']->qux[=91boop=92] ?? NU=
LL already. We also couldn=92t add something like ?-> for arrays, as the ?[=
] syntax is ambiguous (looks like ternary with short array syntax).

Property access could be useful as well, I just didn't want to deal with it=
 for the first version of the RFC. It's actually already listed in "future =
scope". :) If this method call portion goes well, I'd be willing to submit =
an RFC/implementation for that as well, but I wanted to get method calls do=
ne first. (It's also somewhat less clearly useful than method calls, especi=
ally with '??' as you point out, which is why I went with method calls firs=
t :))

> 2) It=92d probably be better if you made a language specification patch b=
efore, not after, the RFC is accepted. Having to specify the syntax and sem=
antics formally can make what the operator does clearer and help to spot is=
sues. Plus, going forward, the language specification should not be an afte=
rthought.

Definitely not an afterthought. I just want to get through all of the "not =
clear if it's going to work" bits -- first, the feasibility of the actual i=
mplementation, then whether the RFC got good reception on internals. I'll m=
ake sure to have a spec diff before the RFC goes up for a vote -- does that=
 sound good?

> Otherwise, though, I=92m in favour of this change.

Thanks for the feedback!

Josh