Re: [RFC] Unary null coalescing operator
| From: | Andrea Faulds | Date: | Wed, 21 Jun 2017 20:15:43 +0000 |
| Subject: | Re: [RFC] Unary null coalescing operator | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-99597@lists.php.net to get a copy of this message | ||
Hi Sara,
Sara Golemon wrote:
On Wed, Jun 21, 2017 at 1:05 PM, Andrea Faulds <ajf@ajf.me> wrote:I'm not entirely sure if you're trolling. But in case you aren't, the main problem with @ as I see it is it's a blunt-force instrument. It doesn't just ignore a specific error, it ignores all errors. If you do, say,Here's a small RFC for a small feature, which I've wondered about for a while: https://wiki.php.net/rfc/unary_null_coalescing_operator What do you think of it?I think thatif ($_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: if (@@$_GET['x'] === 1) The double @@ could indicate "No, really, don't send any kind of warning (or lower) anywhere. Just deal with it. And as a bonus, the @@ syntax is valid in older PHPs (acting like a single @).
myFunction()[0]??, only errors related to the existence of the 0 index are silenced. But in the case of @myFunction()[0], any error the function produces is silenced, no matter how relevant it is. It's the expression equivalent of Pokémon exception handling (Gotta catch 'em all: try {/*…*/} catch (Error $e) {}).
For that reason, I don't like the idea of extending @.
--
Andrea Faulds
https://ajf.me/