Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99619
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <13.F6.52620.31E2C495@pb1.pair.com>
References: <27.FD.13828.277AA495@pb1.pair.com> <CAESVnVpSj8caZ3JxNo2eLNAY_Lj6iEcBsRm2PnXud=_zAoX83w@mail.gmail.com>
 <098eb964-4187-f71a-f076-02fae9b042c6@gmail.com> <13.F6.52620.31E2C495@pb1.pair.com>
Date: Thu, 22 Jun 2017 23:10:22 +0200
Message-ID: <CAF+90c9ja4ZWUV7uWCMsy+Kz0bh8nA76CoE_Bjobqr5nRm+tkQ@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a113ee16ab707f3055292e9cd"
Subject: Re: [PHP-DEV] [RFC] Unary null coalescing operator
From: nikita.ppv@gmail.com (Nikita Popov)

--001a113ee16ab707f3055292e9cd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 22, 2017 at 10:52 PM, Andrea Faulds <ajf@ajf.me> wrote:

> Hi Stas,
>
> Stanislav Malyshev wrote:
>
>> Hi!
>>
>> I think that  `if ($_GET['x']?? =3D=3D=3D 1)` looks and feels a lot like=
 `if
>>> (@$_GET['x'] =3D=3D=3D 1)`...
>>>
>>> Yes, the latter has runtime performance issues and will still send
>>> notices to error handlers and logs.  But perhaps if we're going to
>>> extend syntax, the syntax could be something along the lines of:
>>>
>>
>> I'd rather fix @ (or make another operator like @@ that Sara proposed)
>> to make nullsafe access - and maybe even extend it to full expression
>> like isset/empty does - so I could do something like
>> @$foo['bar']->blah->foo['bah'] and have it mean "try to fetch the whole
>> chain and if something is missing on the way return null". I kinda get
>> the argument for PHP not doing it by default, though I personally could
>> live with that too ;) - but I still need this thing quite frequently
>> when dealing with all kinds of dirty data.
>>
>
> You already can use @. I'm not sure how it could be "fixed": the
> fundamental problem with @ is that it is a blunt-force instrument that
> mutes all errors, but this is also its purpose, and any change to that wi=
ll
> break some use cases. The best fix would be to get rid of it entirely, bu=
t
> we can't do that since it actually has to be used in some cases right now=
,
> in particular standard library functions that produce E_WARNINGs on I/O
> errors.
>
> With trailing ?? it is not clear how it would chain,
>>
>
> It's a unary operator, I don't know what =E2=80=9Cchain=E2=80=9D would me=
an for one. You
> can use it within other expressions (1 + $a?? is valid, for example), and
> you can nest it within itself ($a???? is also valid, though I've no idea
> why you'd do that).
>
> and even if it
>> chains having something at the end that changes how the expression is
>> interpreted is both confusing and may be very hard for the parser.
>>
>
> Unary ?? is a two-line addition to the syntax and completely unambiguous
> from a parsing perspective.
>

As has been pointed out on reddit, unary ?? is ambiguous for cases like
$a?? - 1, which could be either ($a??) - 1 or $a ?? (-1). Of course,
precedence resolution is possible, but I wouldn't call the syntax
unambiguous.

Nikita

--001a113ee16ab707f3055292e9cd--