Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:77272 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 20771 invoked from network); 16 Sep 2014 19:28:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Sep 2014 19:28:47 -0000 Authentication-Results: pb1.pair.com header.from=mails@thomasbley.de; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=mails@thomasbley.de; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain thomasbley.de from 85.13.137.24 cause and error) X-PHP-List-Original-Sender: mails@thomasbley.de X-Host-Fingerprint: 85.13.137.24 dd15934.kasserver.com Received: from [85.13.137.24] ([85.13.137.24:52618] helo=dd15934.kasserver.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 94/09-64534-D6F88145 for ; Tue, 16 Sep 2014 15:28:46 -0400 Received: from dd15934.kasserver.com (dd0802.kasserver.com [85.13.143.1]) by dd15934.kasserver.com (Postfix) with ESMTPSA id 521E22601F3; Tue, 16 Sep 2014 21:28:42 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SenderIP: 95.91.208.158 User-Agent: ALL-INKL Webmail 2.11 To: internals@lists.php.net Cc: ajf@ajf.me Message-ID: <20140916192842.521E22601F3@dd15934.kasserver.com> Date: Tue, 16 Sep 2014 21:28:42 +0200 (CEST) Subject: Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator From: mails@thomasbley.de ("Thomas Bley") Andrea Faulds wrote on 16.09.2014 20:34: > > On 10 Sep 2014, at 10:31, Pierre Joye wrote: > >> On Tue, Sep 9, 2014 at 12:58 AM, Adam Harvey wrote: >>> On 8 September 2014 07:56, Christoph Becker wrote: >>> +1 on ?? — there's precedent for it, and it means we don't have to >>> explain why the shorthand form of an operator behaves differently to >>> the long form, which is just going to confuse users. >> >> After a 2nd look I have to agree here too. Changing behavior in >> something so widely used as the current operator will likely create >> more pains. A new operator, clearly documented, sounds much cleaner, >> even more as it does something different anyway. > > By popular demand, I’ve changed the RFC to instead propose a ?? operator, > after Nikita Popov generously donated a working ?? patch. In doing so, the RFC > is renamed “Null Coalesce Operator”. > > Please read it: https://wiki.php.net/rfc/isset_ternary > > Thanks! > -- > Andrea Faulds > http://ajf.me/ > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > looks good! What are the pros and cons of a new operator vs. a new function? For example, MySQL has a coalesce() function: http://dev.mysql.com/doc/refman/5.6/en/comparison-operators.html#function_coalesce Regards, Thomas