Re: [RFC] Unary null coalescing operator

From: 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:
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 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: 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 @).
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, 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/

« previous php.internals (#99597) next »