Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:99597 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 7700 invoked from network); 21 Jun 2017 20:15:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Jun 2017 20:15:47 -0000 X-Host-Fingerprint: 2.24.106.37 unknown Received: from [2.24.106.37] ([2.24.106.37:18733] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F8/6F-13828-2F3DA495 for ; Wed, 21 Jun 2017 16:15:46 -0400 Message-ID: To: internals@lists.php.net References: <27.FD.13828.277AA495@pb1.pair.com> Date: Wed, 21 Jun 2017 21:15:43 +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: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 2.24.106.37 Subject: Re: [PHP-DEV] [RFC] Unary null coalescing operator From: ajf@ajf.me (Andrea Faulds) Hi Sara, Sara Golemon wrote: > On Wed, Jun 21, 2017 at 1:05 PM, Andrea Faulds 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/