Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:70417 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 74906 invoked from network); 26 Nov 2013 17:54:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Nov 2013 17:54:35 -0000 Authentication-Results: pb1.pair.com smtp.mail=ekneuss@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ekneuss@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.180 as permitted sender) X-PHP-List-Original-Sender: ekneuss@gmail.com X-Host-Fingerprint: 209.85.212.180 mail-wi0-f180.google.com Received: from [209.85.212.180] ([209.85.212.180:48767] helo=mail-wi0-f180.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 72/57-39355-A50E4925 for ; Tue, 26 Nov 2013 12:54:34 -0500 Received: by mail-wi0-f180.google.com with SMTP id hm4so7495128wib.13 for ; Tue, 26 Nov 2013 09:54:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=S9jkB7zD3vEQTOpv0VCzfWBwHM1cYTFjLd3ackbTc98=; b=TInf7Y6vBbH10gDQhHTzJYOwQD9CPBpb6fpX5VnqVLPxkDwJH4x+GHEg8OQ75tx5pH Nva9leqmZwKBsu0MjOXj2hNbm5MOVf4PF1bnXoYKT4t5ZXlVRsnan2NCwEQb0mDeiQTR BlnI6qNeRp5sdKH36OUV123O745hgnZqkIucLv0YBwmVHeTeVq5YCWUfOcx4wJqi+8mb CvBnXLmzdnGeuVNj+Z3cJeGpk5w9Pg7Fmw90L88QSjRsCIo24tpCGN9rT+MKzL+QQIj2 hO74qhb5TY4JxFxCJ7Yu2iCQWtrwEbvEUExBV+tXyPMsUl4QWvRKFBg7zIgQeiFVRE97 nVWQ== X-Received: by 10.180.206.138 with SMTP id lo10mr19101801wic.25.1385488470971; Tue, 26 Nov 2013 09:54:30 -0800 (PST) MIME-Version: 1.0 Sender: ekneuss@gmail.com Received: by 10.216.152.70 with HTTP; Tue, 26 Nov 2013 09:54:10 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Nov 2013 18:54:10 +0100 X-Google-Sender-Auth: gWi9cSki_SsyRjOLPNp8o6i_f7U Message-ID: To: Chris London Cc: Paul Dragoonis , Mats Lindh , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=001a11c26b2627734204ec182c21 Subject: Re: [PHP-DEV] [Proposal] Modification to ?: functionality From: colder@php.net (Etienne Kneuss) --001a11c26b2627734204ec182c21 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 26, 2013 at 6:48 PM, Chris London wrote: > On Tue, Nov 26, 2013 at 10:41 AM, Paul Dragoonis >wrote: > > > > > > > > > On Tue, Nov 26, 2013 at 4:58 PM, Chris London wrote: > > > >> On Tue, Nov 26, 2013 at 8:15 AM, Mats Lindh > wrote: > >> > >> > On Tue, Nov 26, 2013 at 3:43 PM, Chris London > >> wrote: > >> > > >> >> I believe these two statements are functionally equivalent: > >> >> > >> >> $foo = $foo ? $foo : 'default'; > >> >> > >> >> $foo = $foo ?: 'default'; > >> >> > >> > > >> > They are. > >> > > >> > > >> > I would like to change it so it also checks for isset() so I propose > the > >> >> following would be functionally equivalent: > >> >> > >> >> $foo = isset($foo) && $foo ? $foo : 'default'; > >> >> > >> >> $foo = $foo ?: 'default'; > >> >> > >> > > > > We can't change the behaviour of ?: that ship has already sailed, we'll > > just be hurting existing codebases on upgrading and more user education > is > > required to understand non-visual changes in syntax like this, lets try > to > > learn from our mistakes by not changing 'behaviour' anymore. > > > > An alternative syntax that is similar and not ugly would be good since > the > > ?: behaviour was broken from the start since you still need to run > isset() > > before running ?: which was the problem we tried to solve in the first > > place but it just didn't happen. > > > > I don't like the @ symbol it's too different from what's already there on > > the ternary logic. > > > > My reason for the @ symbol was that it's already used to suppress errors so > to me it seems like it could be interpreted as a suppressed ternary but I'm > open to other suggestions. > > > > > > Proposal: $foo = $arr['value'] ?:: ""; > > > > I'd be fine with this choice. > I don't see any value in adding yet another operator for this, we already support this through: $foo = @$arr['value'] ?: ""; > > > > > > Thoughts? > > > > > > >> > The would break the assumption that a reference to an uninitialized > >> value > >> > would generate a notice, unless explicitly handled in the logic. > >> > > >> > While I also would like to have something similar to ?: to handle > >> default > >> > values for array keys, etc., this would change a fundamental > assumption > >> > that as been in place for many years now. I'm not sure if that's a BC > >> break > >> > that would be acceptable this late. An alternative operator may be > more > >> > suitable. > >> > > >> > >> What do you think about using: > >> > >> $foo = $foo @: 'default'; > >> > >> and possibly > >> > >> $foo @= 'default'; > >> > >> > >> > >> > > >> > The change proposed has also been discussed several times since the > >> > implementation of ?:. See the ifsetor-RFC: > >> > > >> > https://wiki.php.net/rfc/ifsetor > >> > > >> > It also contains links to the discussion around the feature back then. > >> > > >> > --mats > >> > > >> > > > > > -- Etienne Kneuss http://www.colder.ch --001a11c26b2627734204ec182c21--