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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
