Re: [RFC] Unary null coalescing operator

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/