Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99618
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <13.F6.52620.31E2C495@pb1.pair.com>
To: internals@lists.php.net
References: <27.FD.13828.277AA495@pb1.pair.com>
 <CAESVnVpSj8caZ3JxNo2eLNAY_Lj6iEcBsRm2PnXud=_zAoX83w@mail.gmail.com>
 <098eb964-4187-f71a-f076-02fae9b042c6@gmail.com>
Date: Thu, 22 Jun 2017 21:52:31 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0)
 Gecko/20100101 Firefox/49.0 SeaMonkey/2.46
MIME-Version: 1.0
In-Reply-To: <098eb964-4187-f71a-f076-02fae9b042c6@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Unary null coalescing operator
From: ajf@ajf.me (Andrea Faulds)

Hi Stas,

Stanislav Malyshev wrote:
> Hi!
>
>> I think that  `if ($_GET['x']?? === 1)` looks and feels a lot like `if
>> (@$_GET['x'] === 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 
will break some use cases. The best fix would be to get rid of it 
entirely, but 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 “chain” would mean 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.

Thanks.
-- 
Andrea Faulds
https://ajf.me/